Gijs Kruitbosch wrote:
On 14/05/2015 18:12, Martin Thomson wrote:
I have no idea what you are talking about. I have never had cause to
use new String() anywhere. .toString() maybe.
There are more than 1000 hits for new String( in MXR, so our
codebase disagrees.
Most if these are in JS
On Thu, May 14, 2015 at 11:22 PM, Gijs Kruitbosch gijskruitbo...@gmail.com
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
On Thu, May 14, 2015 at 11:16 PM, Panos Astithas p...@mozilla.com wrote:
This. From the perspective of a library method validating inputs, I've
always found it pays off to rely on Postel's principle.
Sorry, that's a red flag for me. Postel was wrong. (Search for that phrase.)
Indeed, a good argument could be made that the old quirks mode years of
the web were a strong example of the web suffering a lot while learning
this very lesson (and modern web standardization processes work pretty hard
to try and avoid it).
Dan
On Fri, May 15, 2015 at 9:47 AM, Martin Thomson
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 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,
On 14/05/2015 18:12, Martin Thomson wrote:
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com 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
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com 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
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com 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.
On 14/05/2015 17:14, Martin Thomson wrote:
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com wrote:
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
mattn+firefox-...@mozilla.com wrote:
In JavaScript, == is preferred to ===. from
On Thu, May 14, 2015 at 9:14 AM, Martin Thomson m...@mozilla.com wrote:
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com wrote:
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
mattn+firefox-...@mozilla.com wrote:
In
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com wrote:
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
mattn+firefox-...@mozilla.com wrote:
In JavaScript, == is preferred to ===. from
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 involved.
On 14/05/2015 19:08, Martin Thomson wrote:
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com 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
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,
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
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
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
On 14/05/2015 22:55, Eric Rescorla wrote:
On Thu, May 14, 2015 at 1:22 PM, Gijs Kruitbosch
gijskruitbo...@gmail.com 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
19 matches
Mail list logo
