Both of these were added to the spec. in ES3. They are probably
exactly the sort of thing I was warning against when I mentioned point
in time or spec. writer introduced inconsistencies.
Yup.
(I was off TC39 TG1 not paying close attention, founding mozilla.org -- sorry. :-P)
I don't think we should use ES3's aberrations to justify more like those.
Was there any reason that it was decided to keep the in operator throwing
on primitive values, or was it just a matter of "I don't think it matters
too much"?
For example, "1" in 3 will throw a TypeError.
On Mar 4, 2012, at 3:24 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
Both of these were added to the spec. in ES3. They are probably
>> exactly the sort of thing I was warning against when I mentioned point
>> in time or spec. writer introduced inconsistencies.
>
>
Yup.
>
(I was off TC39 TG1 not paying close attention, founding mozilla.org --
> sorry. :-P)
>
I don't think we should use ES3's aberrations to justify more like those.
>
/be
Was there any reason that it was decided to keep the in operator throwing
on primitive values, or was it just a matter of "I don't think it matters
too much"?
For example, `"1" in 3` will throw a TypeError.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140410/053f55af/attachment.html>
On Mar 4, 2012, at 3:24 PM, Brendan Eich wrote:
Was there any reason that it was decided to keep the in operator throwing on primitive values, or was it just a matter of "I don't think it matters too much"?
For example,
"1" in 3will throw a TypeError.