On Thu, May 14, 2015 at 11:22 PM, Gijs Kruitbosch
wrote:
> My point is there will be just as many "unexpected" issues when you use
> "===" on opaque variables, because you didn't expect that that code in that
> other file set this thing to null instead of deleting the property (causing
> it to no
On 5/14/15 4:22 PM, Gijs Kruitbosch wrote:
On 14/05/2015 19:08, Martin Thomson wrote:
If you intend to support false and null and undefined and NaN and
attribute the same semantics, _say so_. Make it explicit. Don't make
me (the person reading your code years later) that this is your
intent.
On 14/05/2015 23:15, Adam Roach wrote:
On 5/14/15 16:33, Gijs Kruitbosch wrote:
Can you give a concrete example where you had to change a
contributor's patch in frontend gaia code to prefer === to prevent
real bugs?
From what I've seen, it's typically a matter of making the results
unsurpri
> How many of these can you correctly predict the result of?
Knowing Gijs, I know the answer is "all of them" :)
This is certainly a factor in this discussion - how familiar you are
with JS, and how much you use it every day, certainly affects your
perspective. Gijs' (and my) experience is that u
On 5/14/15 16:33, Gijs Kruitbosch wrote:
Can you give a concrete example where you had to change a
contributor's patch in frontend gaia code to prefer === to prevent
real bugs?
From what I've seen, it's typically a matter of making the results
unsurprising for subsequent code maintainers, be
On 14/05/2015 22:55, Eric Rescorla wrote:
On Thu, May 14, 2015 at 1:22 PM, Gijs Kruitbosch
mailto:gijskruitbo...@gmail.com>> wrote:
Maybe there is a difference with firefox browser JS and platform
JS here (on which you seem to be working), in terms of which kinds
of type confusion
On 14/05/2015 21:45, Andrew Sutherland wrote:
On 05/14/2015 04:22 PM, Gijs Kruitbosch wrote:
"==" is not any less explicit than "===". Both versions have an exact,
specified meaning.
They both have exact meanings. But people, especially new contributors
new to JS, frequently use "==" without
On 05/14/2015 04:22 PM, Gijs Kruitbosch wrote:
"==" is not any less explicit than "===". Both versions have an exact,
specified meaning.
They both have exact meanings. But people, especially new contributors
new to JS, frequently use "==" without understanding the nuances and
footguns involv
On 14/05/2015 19:08, Martin Thomson wrote:
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
wrote:
I mean, obviously the example is simplified. You seem to think that "==="
means "I'm sure this will be the right type". In the same way you imply that
== indicates uncertainty about type (or acce
On Thu, May 14, 2015 at 12:18 PM, wrote:
> 1. What information do dependent APIs need to store? I can think of:
> a) appID
> b) inBrowserElement
> c) origin
> d) scope
> e) (optional) manifestURL when appID is not UNKNOWN?
> Can any or all of these be replaced by a nsIPrincipal and something else
Hello,
As part of allowing various APIs (Push notifications, Notifications,
BackgroundSync etc.) to use ServiceWorkers, we need some way to start them in
the child process. I'm trying to figure out how to do this properly in e10s and
on b2g. Here is an outline, I'm hoping someone with more know
On 5/14/15 1:35 PM, Gijs Kruitbosch wrote:
var foo = [1,2,3];
window.open('bar.html', '_blank', '', foo);
in bar.html, checking the type of foo using instanceof with Array fails.
For builtin Arrays we now have isArray, but this does not work for
custom JS classes or DOM elements.
Actually, DOM
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
wrote:
> I mean, obviously the example is simplified. You seem to think that "==="
> means "I'm sure this will be the right type". In the same way you imply that
> == indicates uncertainty about type (or acceptance of multiple types), I
> would arg
On 14/05/2015 18:12, Martin Thomson wrote:
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
wrote:
Crockford offers plenty of
reasons in his book.
I've not read Crockford's book and have no plans to, but there are plenty of
reasons against, too. :-)
Do you want me to send you a copy?
No,
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
wrote:
> Do you think the people that wrote the style guide (not me, so I'm not
> trying to be defensive over the document, to be clear) did not understand
> what they wrote? :-)
No, but I do think that they were wrong.
>> Crockford offers plenty
On Thu, May 14, 2015 at 9:14 AM, Martin Thomson wrote:
> On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
> wrote:
> > On 14/05/2015 01:21, Martin Thomson wrote:
> >>
> >> On Wed, May 13, 2015 at 4:54 PM, Matthew N.
> >> wrote:
> >>>
> >>> "In JavaScript, == is preferred to ===." from
> >>>
> >
On 14/05/2015 17:14, Martin Thomson wrote:
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
wrote:
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
wrote:
"In JavaScript, == is preferred to ===." from
https://developer.mozilla.org/en-US/docs/Mozilla/D
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
wrote:
> On 14/05/2015 01:21, Martin Thomson wrote:
>>
>> On Wed, May 13, 2015 at 4:54 PM, Matthew N.
>> wrote:
>>>
>>> "In JavaScript, == is preferred to ===." from
>>>
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_St
On 2015-05-14 8:03 AM, Mike de Boer wrote:
On 14 May 2015, at 03:15, Boris Zbarsky wrote:
On 5/13/15 7:35 PM, Gregory Szorc wrote:
I would steer people in the direction of Assert.jsm, specifically
Assert.deepEqual
This should be used very very carefully.
As a very simple example, using th
On 5/14/15 8:03 AM, Mike de Boer wrote:
Same goes for Gecko wrapper objects, like `window`. When you want to use
`deepEqual` with those, anyone should feel free to add support for it!
Here's the thing. When comparing window objects, in what sense would
anything other than === be useful?
An
On 13/05/15 06:29 PM, Gregory Szorc wrote:
On Wed, May 13, 2015 at 2:03 PM, Ms2ger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/13/2015 09:54 PM, Andrew Halberstadt wrote:
As mentioned previously in another post, work is under way to
remove the flavor specific mochitest command
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
wrote:
"In JavaScript, == is preferred to ===." from
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Operators
Ahh, that's where it was hiding. Can we reverse that statement
On 14/05/15 00:35, Gregory Szorc wrote:
I would steer people in the direction of Assert.jsm, specifically
Assert.deepEqual, which uses ObjectUtils.jsm goodness for type aware
comparisons so things like Date, RegExp, and Object comparisons have sane
behavior. (deepEqual falls back to === for non-s
> On 14 May 2015, at 03:15, Boris Zbarsky wrote:
>
> On 5/13/15 7:35 PM, Gregory Szorc wrote:
>> I would steer people in the direction of Assert.jsm, specifically
>> Assert.deepEqual
>
> This should be used very very carefully.
>
> As a very simple example, using this (or worse yet notDeepEqua
24 matches
Mail list logo
