Re: Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()
Hiya, > [Enumerate]] must obtain the own property keys of the target object as if by calling its [[OwnPropertyKeys]] internal method Whoa that's tricky language. I assumed reading it that [[Enumerable]] was to follow the order of [[OwnPropertyKeys]] (as part of "as if by") and walking the prototype chain. It's odd to me that: Reflect.ownKeys() has defined order but Reflect.enumerate() doesn't I'm using Reflect.enumerate() to create a `keysIn` implementation (like `keys` but for own & inherited key names). :+1: for more defined behavior in ES7. - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.trimRight/trimLeft
In the wild I've seen ltrim rtrim which are variations of trimLeft and trimRight and padLeft padRight or lpad, rpad for other forms. For stings I think of left and right as leading and trailing and think of start and end as more position indicators of like slice or a range. -JDD On Mon, Jul 27, 2015 at 4:55 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: OK, it was added to the agenda for the next meeting (will be presented by Sebastian Markbage), so can be discussed in detail. I agree that start, and end are now probably better fit (because of i18n, and a strong correlation with startsWith and endsWith). We can probably ignore the de-facto shipped in browsers, they will just implement in addition `trimStart` and `trimEnd`, and eventually deprecate the right and left. Dmitry On Tue, Jul 21, 2015 at 12:02 AM, Claude Pache claude.pa...@gmail.com wrote: Le 21 juil. 2015 à 08:28, Jordan Harband ljh...@gmail.com a écrit : On the contrary -left always begins at index 0 - start is sometimes index 0, sometimes index (length - 1). Counter-example: ES6 methods `String#startsWith` and `String#endsWith` are named correctly. I think left and right are the right names; start and end would require unicode bidirectional stuff. No, because characters in Unicode strings are ordered logically, not visually. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@toStringTag spoofing for null and undefined
Primary issue is in isTypedArray(a): Uin32Array.prototype.buffer.call(a); Besides the typos, accessing .buffer throws in at least Chrome Firefox. Then .buffer is an object so if it doesn't throw there's no .call to execute. -JDD On Wed, Jan 28, 2015 at 4:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 28, 2015, at 4:40 PM, John-David Dalton john.david.dal...@gmail.com wrote: Kind of a bummer. The isTypedArray example from https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-59 is incorrect. Is there an updated reference somewhere? The toStringTag result is handy because it allows checking against several tags at once without having to invoke multiple functions each with their own try-catch and all that perf baggage. How is it incorrect? Are you referring to the fact that both typed arrays and DataView objects have a [[ViewedArrayBuffer]] internal slot. If so, I think this is a specification but that I should fix. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@toStringTag spoofing for null and undefined
Kind of a bummer. The isTypedArray example from
https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-59
is
incorrect. Is there an updated reference somewhere?
The toStringTag result is handy because it allows checking against several
tags at once without having to invoke multiple functions each with their
own try-catch and all that perf baggage.
- JDD
On Wed, Jan 28, 2015 at 4:29 PM, Jordan Harband ljh...@gmail.com wrote:
To summarize the discussion at today's TC39 meeting:
Given that the style of checks that Allen proposed (
https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-59
) (using non-side-effecty non-generic methods that rely on internal slots,
in a try/catch) is indeed reliable in ES3, and will continue to be reliable
in ES6, any security-conscious code should update itself to use these kinds
of checks rather than an Object.prototype.toString.call check. v8 (and any
other implementations that are working on @@toStringTag) will leave
Symbol.toStringTag behind a flag for a full two months, to give the
relevant code time to release updates.
In addition, anybody who modifies a builtin so that, say, a Boolean
reports itself as a Number, surely intends the effects of this change, and
so there is no concern about them. In accordance with this, step 17b of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring
will be removed - if a developer wants to make a non-builtin value
masquerade as a builtin, they similarly are intending those effects.
I've updated and/or released the following npm packages to remain
resilient with respect to this change in case anyone wants some specific
examples of how to implement this:
- https://www.npmjs.com/package/is-equal
- https://www.npmjs.com/package/is-date-object
- https://www.npmjs.com/package/is-number-object
- https://www.npmjs.com/package/is-regex
- https://www.npmjs.com/package/is-symbol
In addition, I've closed and added similar comments to the spec bug I
originally filed: https://bugs.ecmascript.org/show_bug.cgi?id=3506
Thanks, everyone, for your thoughts and time!
- Jordan
On Sat, Jan 24, 2015 at 2:59 PM, Mark Miller erig...@gmail.com wrote:
Put better, the spec requires that Object.freeze(Object.prototype) works.
On Sat, Jan 24, 2015 at 2:57 PM, Mark Miller erig...@gmail.com wrote:
On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows impinb...@gmail.com
wrote:
From: Mark S. Miller erig...@google.com
To: Gary Guo nbdd0...@hotmail.com
Cc: es-discuss@mozilla.org es-discuss@mozilla.org
Date: Sat, 24 Jan 2015 07:11:35 -0800
Subject: Re: @@toStringTag spoofing for null and undefined
Of course it can, by tamper proofing (essentially, freezing)
Object.prototype. None of these protections are relevant anyway in an
environment in which the primordials are not locked down.
Yeah, pretty much. That proverbial inch was given a long time ago. And
the proverbial mile taken. And I highly doubt the spec is going to require
`Object.freeze(Object.prototype)`,
Of course not. The key is the spec allows it. SES makes use of that.
since that prohibits future polyfills and prolyfills of the Object
prototype. Also, you could always straight up overwrite it, but that's even
harder to protect against. (And how many cases do you know of literally
overwriting built-in prototypes?)
Or, to throw out an analog to Java, it is perfectly possible to call or
even override a private method through reflection. JavaScript simply has
more accessible reflection, more often useful since it's a more dynamic
prototype-based OO language as opposed to a stricter class-based language.
On Sat, Jan 24, 2015 at 6:11 AM, Gary Guo nbdd0...@hotmail.com
wrote:
Now I have a tendency to support the suggestion that cuts the
anti-spoofing part. If coder wants to make an object and pretend it's a
built-in, let it be. The anti-spoofing algorithm could not prevent this
case:
```
Object.prototype.toString = function(){
return '[object I_Can_Be_Anything]';
}
```
Or this:
```js
function handler() {
throw new Error(No prototype for you!);
}
Object.defineProperty(
Object,
'prototype',
{
get: handler,
set: handler,
enumerable: true
});
```
Me thinks this isn't going to get fixed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
Re: @@toStringTag spoofing for null and undefined
At the moment that throws too. Anyways it's something to hammer on a bit. Maybe Jordan can kick it around too. Thanks, -JDD On Wed, Jan 28, 2015 at 5:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 28, 2015, at 5:03 PM, John-David Dalton john.david.dal...@gmail.com wrote: Primary issue is in isTypedArray(a): Uin32Array.prototype.buffer.call(a); Besides the typos, accessing .buffer throws in at least Chrome Firefox. Then .buffer is an object so if it doesn't throw there's no .call to execute. the ES6 definition of %TypedArray%.prototype.buffer: %TypedArray%.prototype.buffer is an *accessor property* whose set accessor function is undefined. Its get accessor function performs the following steps: 1. Let O be the this value. 2. If Type(O) is not Object, throw a TypeError exception. 3. If O does not have a [[ViewedArrayBuffer]] internal slot throw a TypeError exception. 4. Let buffer be the value of O’s [[ViewedArrayBuffer]] internal slot. 5. Return buffer. ES6 expects buffer to be implemented as an accessor property. That means that the probe in my test should be: Object.getOwnProperty(Uint32Array.prototype.__proto__, ‘buffer’).get.call(a); Allen -JDD On Wed, Jan 28, 2015 at 4:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 28, 2015, at 4:40 PM, John-David Dalton john.david.dal...@gmail.com wrote: Kind of a bummer. The isTypedArray example from https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-59 is incorrect. Is there an updated reference somewhere? The toStringTag result is handy because it allows checking against several tags at once without having to invoke multiple functions each with their own try-catch and all that perf baggage. How is it incorrect? Are you referring to the fact that both typed arrays and DataView objects have a [[ViewedArrayBuffer]] internal slot. If so, I think this is a specification but that I should fix. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
MooTools breaking because of additions/changes is not a new thing. It has been broken in the past by things like Function#bind, String#contains, Moz removing document.getBoxObjectFor. Its activity has slowed overall though there is an effort to re-energize core contributions. Their core has put effort towards another project, Prime, which does not augment native prototypes. -JDD On Tue, Sep 30, 2014 at 12:45 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. It's also common on the old web to loop over Arrays via `for/in` to avoid checks for sparse indexes through the entire length ... so making anything enumerable in that native prototype would break something else too form days where `getOwnPropertyNames` was unknown. long story short: I definitively +1 what Michał Wadas already said, it's already patched and people must update software anyway due security problems, **patches**, etc etc. just my .02 On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 2:45 PM, Michał Wadas wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. I didn't say we need to make it enumerable. I said that given the current state of the web, a web browser cannot ship a non-enumerable method named contains on Array.prototype. The options, therefore, are: 1) Make the method enumerable. 2) Name the method something else. 3) Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago). I'm perfectly fine with option 3, personally. Note that in practice that likely means never ship it unless people make some sort of concerted effort to get sites to update their MooTools version. -Boris P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains. - JDD On Tue, Sep 30, 2014 at 1:29 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 3:45 PM, Andrea Giammarchi wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. They have ears, but cannot hear... This is a reasonably commonly used library, as libraries go. This may be helpful: http://trends.builtwith.com/javascript/javascript-library Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
There is no need to change the name. MooTools has had these issues in the past (they've broke with ES5, ES6, ES7 methods). Array#contains is ES7 so there's time for their patch to release/propagate. - JDD On Tue, Sep 30, 2014 at 3:04 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas michalwa...@gmail.com wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. Well -- true, that would break even more sites. We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contribution. In the long run, perhaps renaming it is the best course? :-\ -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
Did you ask them to fix their code so it doesn't fail for any name, not just for 'contains'? Thanks, I didn't, but will follow up with that. JDD On Tue, Sep 30, 2014 at 3:50 PM, Brendan Eich bren...@mozilla.org wrote: John-David Dalton wrote: Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains. Did you ask them to fix their code so it doesn't fail for any name, not just for 'contains'? Thanks, /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
So put ES7 features behind a flag until the water clears a bit. We'll get there. It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again. JDD On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems. Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that. it is also already patched and it's also a small fix. The 6.5% of existing web sites using JS libraries that use MooTools have not been already patched. Patching 3.5 million web sites is not a small fix in any relevant sense. It simply will not be done thoroughly or soon. If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway. Yes. You have correctly identified incentives as a problem. That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. Reductio ad the-world-is-not-as-I-wish-it-to-be is not a thing. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains solutions
A more general solution seems like a good idea. Renaming doesn't really solve the deeper issue. Extending native prototypes is a JavaScript thing and something that will most likely continue continue. Ember adds methods to Array.prototype and Function.prototype by default: http://emberjs.com/api/classes/Ember.Array.html#method_contains (btw their Array#contains is not ES7 spec compliant either) then there's the oldie Prototype.js: http://api.prototypejs.org/ and alternatives like Sugar.js: http://sugarjs.com/api that's a lot to watch out for. JDD On Tue, Sep 30, 2014 at 5:03 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola Or you could attack the problem at the for-in level This half-sentence was a leftover from an earlier pass; please ignore it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains solutions
Maybe. Though there would still be issues with implementations not aligning, like Ember which does use defineProperty to make them non-enumerable and doesn't pave existing methods, as well as issues with scripts that support pre-ES5 environments that don't want enumerable inconsistency. JDD On Tue, Sep 30, 2014 at 5:15 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 8:12 PM, John-David Dalton wrote: Extending native prototypes is a JavaScript thing and something that will most likely continue continue. Note that if people were extending in nice ways, using defineProperty and making their props non-enumerable instead of just doing a [[Set]], that would significantly reduce issues like this... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have
settled on using Object.prototype.toString.call as a way to determine the
kind of a value and don't expect that to throw.
This is edge case but it seems like an unnecessary gotcha to throw at devs.
- JDD
On Fri, Aug 29, 2014 at 11:57 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Fri, Aug 29, 2014 at 5:09 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Wouldn't that be inconsistent with `{}.toString.call(String.prototype)`
and
all others ?
It is inconsistent, but it's a change TC39 deliberately chose to take.
It's a good change. The fact that Date.prototype is a real Date
object, for example, has been a common source of bugs and general
weirdness.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
I will fix the handful of standard @@toStringTag getters so they don't throw That's rad! But I can't really really do anything about user written @@toStringTag getter that throw or for that matter objects that use Proxies to throw. Ya, that's fine. - JDD On Fri, Aug 29, 2014 at 1:58 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 29, 2014, at 12:10 PM, John-David Dalton wrote: JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have settled on using Object.prototype.toString.call as a way to determine the kind of a value and don't expect that to throw. This is edge case but it seems like an unnecessary gotcha to throw at devs. We've explicitly designed the ES6 O.p.toString to preserve the [[Class]] type branding that was proved by prior editions but also decided to explicitly not support any new primitive [[Class]]-like brand values. Going forward it isn't a reliable way to type check or brand new built-in or programmer defined types. I will fix the handful of standard @@toStringTag getters so they don't throw. But I can't really really do anything about user written @@toStringTag getter that throw or for that matter objects that use Proxies to throw. So, unless you wan to argue for eating exceptions in O.P.toStringm, that possibility will remain but is likely the reflection of a bug or malicious code. Presumablly, such problems can be diagnosed via a debugger allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
Rock, will do. Thanks! - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the
keys of `source` objects. This helps avoid the method gotchas faced by
developers previously with things like `Object.prototype.writable = true`
and `Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description(bottom
of section)
Bear in mind that these options are not necessarily own properties so, if
inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all
options explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even
though false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make
sense to make things like ToPropertyDescriptor use [[HasOwnProperty]] too.
I think it would be a win for consistency and dev use.
Thoughts?
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
I agree with you that this would be a much better design, but it would
break backwards compatibility with ES5, no?
There have been other changes to the spec that are technically back-compat
breaking like Object.keys('x') no longer throwing an error.
I think this change would benefit developers as the case seems to be devs
getting bitten by the current behavior.
Minor nitpick: I guess you mean to say that ToPropertyDescriptor should
use the abstract operation HasOwnProperty, not [[HasOwnProperty]]
Sure, I'll switch to ES6y terms. Yes, I mean the abstract operation
HasOwnProperty.
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
Thanks for the discussion links, Allen. I'm I reading it right that there was no concrete resolution to the issue? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
Is Post-ES6 up for discussion? Should I create a spec bug for tracking this? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. On Fri, Dec 14, 2012 at 8:39 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. That's my point. Normally testing for NaN can be done via `myNaN !== myNaN` but `Object(NaN)` throws a wrench in that. It would be great if there was 1 function that was able to detect NaN, instead of having libs step up and do it. -JDD On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall nathan.w...@live.com wrote: Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing against the object is different. Nothing breaks. var myNaN = Object(NaN); [ 1, 3, myNaN ].indexOf(myNaN); // = 2 Works as expected. The only problem which occurs is when you're working with primitive NaN, in which case the only existing good ways to test for it are `x !== x` and `typeof x == 'number' isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to test this case which is easier to read and understand. Note that if `x = Object(NaN)` both of these tests fail. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
Bendan Eich wrote:
Your modernizr true-wrapping Boolean example is both a WTFJS moment,
easily avoided by using a truthy object as Sam pointed out, and nothing to
do with NaN.
The Modernizr example was in response to Axel's request for an example of
boxed values being used in real world projects.
I love how the thread got sidetracked by that one ;D
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods or equivalents that equate boxed and unboxed values as
similar:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed alike in their `isXyz`
I think the spec should follow.
On Fri, Dec 14, 2012 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote:
John-David Dalton wrote:
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
That's my point. Normally testing for NaN can be done via `myNaN !==
myNaN` but `Object(NaN)` throws a wrench in that.
It would be great if there was 1 function that was able to detect NaN,
instead of having libs step up and do it.
Why? Who wraps NaN? Your modernizr true-wrapping Boolean example is both a
WTFJS moment, easily avoided by using a truthy object as Sam pointed out,
and nothing to do with NaN.
/be
-JDD
On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall nathan.w...@live.commailto:
nathan.w...@live.com wrote:
Wat? This seems to be a good reason to allow `Object(NaN)` and
use the
NumberWrapper brand as it cannot be tested via the normal way of
`myNaN !== myNaN`.
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing
against the object is different. Nothing breaks.
var myNaN = Object(NaN);
[ 1, 3, myNaN ].indexOf(myNaN); // = 2
Works as expected. The only problem which occurs is when you're
working with primitive NaN, in which case the only existing good
ways to test for it are `x !== x` and `typeof x == 'number'
isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to
test this case which is easier to read and understand. Note that
if `x = Object(NaN)` both of these tests fail.
Nathan
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
I apologize for the duplicate post, but I think my reply got lost in its
formatting.
The Modernizr example was in response to Axel's request for an example of
boxed values being used in real world projects.
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods or equivalents that treat boxed and unboxed values as like:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed the same in their
`isXyz` I think it's natural for the spec to follow in the case of
`Number.isNaN`.
Thanks,
-JDD
On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
[es-discuss-bounces@mozilla.**orges-discuss-boun...@mozilla.org]
on behalf of Nathan Wall [nathan.w...@live.com]
Sent: Friday, December 14, 2012 13:34
On another note, I do sort of wonder why `Number.isNaN` is coming into
the language now at the same time as the `is` operator and `Object.is`. It
seems teaching people (and getting them to remember long-term) the nuances
of `isNaN` and `Number.isNaN` will be more difficult than just teaching
people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6
shims environment.
`is` operator is dead :( :( :(
Restricted productions creating new operators may be at risk (Allen's
right, we haven't had an orderly decision in TC39 on this point), but
Object.is or Object.isSameValue is definitely not dead.
Allen's right too that we have some disagreement on the use of SameValue
under the hood in Map and Set.
/be
(Someone want to find a link to the minutes that killed it? I keep having
to correct people on this.)
There's not an `isNull` or `isUndefined`. The only reason `isNaN` was
needed was because `===` didn't work with `NaN`, but `is` does.
This is pretty reasonable, actually. The only argument I can see is that
`array.filter(Number.isNaN)` is shorter than `array.filter(x =
Object.is(x, NaN))`.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Number.isNaN
I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just
an oversight? I know `Object(NaN)` is totally edge case but it still has
the brand of BultinNumberWrapper and is NaN (boxed).
On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban lu...@microsoft.com wrote:
From: Mark S. Miller [mailto:erig...@google.com]
In that case, the current spec is wrong. The purpose of introducing
Number.isNaN is to repair the following bug in the global isNaN:
isNaN(foo) // returns true
Indeed, as Yusuke noted on the other reply, I referred to the wrong
'isNaN'. And as you note, the point of the 'Number.isNaN' variant is to
avoid any coercions.
That still leave's JDD's original suggestion to allow
Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive
or boxed Number. It feels a little odd to introduce another kind of
limited coercion into the language, but perhaps it is practically valuable
to not differentiate boxed and unboxed numbers here?
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
No. Object.is correctly reports that these are different.
Ah yap, I've had my head in lib code for a while. I'm used to the behavior
of `_.isEqual(3, Object(3)); // = true`
but you're right the current behavior of `Object.is(3, Object(3)); //
false` so yap it makes sense that it's that way for `NaN` and `Object(NaN)`
as well.
On Thu, Dec 13, 2012 at 8:36 PM, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this
just
an oversight?
No. Object.is correctly reports that these are different.
I know `Object(NaN)` is totally edge case but it still has the
brand of BultinNumberWrapper and is NaN (boxed).
On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban lu...@microsoft.com wrote:
From: Mark S. Miller [mailto:erig...@google.com]
In that case, the current spec is wrong. The purpose of introducing
Number.isNaN is to repair the following bug in the global isNaN:
isNaN(foo) // returns true
Indeed, as Yusuke noted on the other reply, I referred to the wrong
'isNaN'. And as you note, the point of the 'Number.isNaN' variant is to
avoid any coercions.
That still leave's JDD's original suggestion to allow
Number.isNaN(Object(NaN)) to return 'true' by checking for either
primitive
or boxed Number. It feels a little odd to introduce another kind of
limited
coercion into the language, but perhaps it is practically valuable to
not
differentiate boxed and unboxed numbers here?
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
Honest question: I have yet to see boxed values in practice. Are there any real use cases? See Modernizr: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23 -JDD On Thu, Dec 13, 2012 at 8:26 PM, Axel Rauschmayer a...@rauschma.de wrote: Honest question: I have yet to see boxed values in practice. Are there any real use cases? [[[Sent from a mobile device. Please forgive brevity and typos.]]] Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com On 14.12.2012, at 05:18, Luke Hoban lu...@microsoft.com wrote: From: Mark S. Miller [mailto:erig...@google.com] In that case, the current spec is wrong. The purpose of introducing Number.isNaN is to repair the following bug in the global isNaN: isNaN(foo) // returns true Indeed, as Yusuke noted on the other reply, I referred to the wrong 'isNaN'. And as you note, the point of the 'Number.isNaN' variant is to avoid any coercions. That still leave's JDD's original suggestion to allow Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive or boxed Number. It feels a little odd to introduce another kind of limited coercion into the language, but perhaps it is practically valuable to not differentiate boxed and unboxed numbers here? Luke ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: default `deleteCount` value of `Array.prototype.splice`
Just checked and IE8 returns `[]` correctly w! On Tue, Jul 3, 2012 at 8:49 AM, John-David Dalton john.david.dal...@gmail.com wrote: I recently saw something like var a = ['a', 'b', 'c', 'd']; a.splice(2); // - ['c', 'd'] in latest Chrome, Opera, Firefox, Safari, Rhino, RingoJS, you name it by spec though I thought the `deleteCount` should be `0` and so return `[]`. http://es5.github.com/#x15.4.4.12 Let *actualDeleteCount* be min(max(ToIntegerhttp://es5.github.com/#x9.4 (*deleteCount*),0),*len* –* actualStart*). var a = ['a', 'b', 'c', 'd']; a.splice(2, 0); // - [] Am I reading it wrong or is this a bug in most engines? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array#splice sparse array spec question.
Can someone confirm/reject that by spec (http://es5.github.com/#x15.4.4.12): // sparse array ;D var a=[0]; a[2]=2; // the resulting arrays length should be 1 and not 2 console.log(a.splice(0, 2).length); I'm seeing `2` in latest Chrome/FF. Thanks, -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@MarkM Is there something magical about the behavior of this object itself? For kicks the magical bit would be its awesome pre ES6 internal [[Class]] value. Can we leave magical out of a spec convo? Note that just because the object itself is non-standard and provided by the host does not make it a host object. http://es5.github.com/#x4.3.8 A host object is an object supplied by the host environment to complete the execution environment of ECMAScript. Seems like the `opera` object falls into that description. I mean it could be a built-in if supplied by the ECMAScript environment but that's beside the point. I really just want the wiggle room that ES5.x provides for [[Class]]/flags/tags/brands. -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@Allen I probably need to be more explicit about host objects and add another step just before step 5 If O is a host object, let tag be an implementation defined string value. The value may not be Array, Boolean, Date, Error, Function, JSON, Math, Number, Object, RegExp, and String. +1 for less complex solution and a continuation of the pre-ES6 wording. Also, the definition of Host Object needs to be tighten up to make it clear that an object is only a host object if it has some magical behavior. -1 magical. Finally, window.opera is really just a normal object it could use my proposed private name based mechanism to set its toString tag. -1 for the more complex option. -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@Allen We want to be able to define things that were historically implemented as host objects using pure ECMAScript code. One things such objects have done is to extend the range of values produced by Object.prototype.toString. So, we need a pure ECMAScript way to accomplish that. You could simplify it by making `NativeArray = Array` and `NativeRegExp = RegExp` and so on. Then you could drop the Tags table and extending the range of Object#toString is as easy as adding a custom [[NativeBrand]] property value. - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@Allen
and name the internal property [[Class]]. But then, how would you
implement it in pure ES code?
You can name the internal property whatever you want [[Class]] /
[[NativeBrand]] / [[Whatevz]]. It's internal so less important to me
what the name is.
I don't think setting [[NativeBrand]] or having a mechanism for
returning custom Object#toString values should be allowed outside of
the ES implementation internals (ignoring overwriting the method with
a dev defined method).
This is one of the reasons why `{}.toString.call(window.opera)` is
such a strong inference because it's harder to fake w/o mucking with
the Object.prototype.
Also note that [[Class]] doesn't actually exist as string valued per object
state in many implementations. That is one of the problems with the current
spec, it creates the impression that it such state actually exists.
Sounds like a per implementation issue/detail. I'm sure there are lots
of internal corners cut in every implementation.
-JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@/be No, we do not want normative spec language requiring a per-object private-named property that determines the Object.prototype.toString.call(x).slice(8,-1) result. Doing this naively will both impose unacceptable overhead *and* allow type-confusion attacks. I'm talking about adding back the wording that ES5.x currently has allowing host objects to set their own internal [[Class]] (or whatever it's new incarnation is) value. Most objects will still have an internal [[NativeBrand]] property of some kind associated with them so I don't see how this is an overhead concern. Not at the price of per-instance class-name. The current ES6 draft handles this by allowing objects to *not* have a [[NativeBrand]] property specified as `Object#toString` will simply return [object Object]. - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@/be This too may be ok if not observable. But you wrote: You could simplify it by making `NativeArray = Array` and `NativeRegExp = RegExp` and so on. Then you could drop the Tags table and extending the range of Object#toString is as easy as adding a custom [[NativeBrand]] property value. and Allen then replied: But then, how would you implement it in pure ES code? Sorry for the confusion. I wasn't suggesting exposing this stuff. I think the [[NativeBrand]] property should be internal. -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
@MarkM
A host object is an object supplied by the host environment to
complete the execution environment of ECMAScript.
Sigh. This came up last time as well, and as participants in the spec
writing process our only excuse was That text isn't normative. That
doesn't really excuse it from being so wrong that it leads people into
endless confusion. If ES6 does keep the current terminology, we must at
least fix or remove this confusing text.
JavaScript was my first language so I don't have the pollution of
Java-isms to confuse me.
I can only go by what's spec'ed as I lack the inside info ;)
Native object: http://es5.github.com/#x4.3.6
Built-in object: http://es5.github.com/#x4.3.7
Host object: http://es5.github.com/#x4.3.8
I should stress that the technical category of the object is less
important to me.
I really just wanted to +1 allowing objects like `window.opera` to
continue to have `{}.toString.call(...)` results like `[object Opera]`
under ES6.
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Read access to [[Class]]?
I noticed in the ES6 draft it states that host objects *do not* have
the [[NativeBrand]] internal property.
I think do not have should be reworded to are not required to have.
This would allow existing inferences like
`{}.toString.call(window.opera) == '[object Opera]'`.
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Just a bit of back story on Function#bind because I think it's good to know.
Prototype's Function#bind was based on the 2004 post Object-Oriented
Event Listening through Partial Application in JavaScript by Daniel
Brockman:
http://web.archive.org/web/20100901172230/http://brockman.se/2004/method-references/
There was no de-facto standard of Function#bind. ExtJS, PrototypeJS,
MooTools, Dojo, and jQuery each had their own implementations.
MooTools Function#bind used to be implemented like:
function fn() {
console.log([].slice.call(arguments));
}
var f = fn.bind({}, ['a', 'b']); // notice an array of arguments
f('c'); // ['a', 'b'] // ignored arguments passed to the bound function
Ext's implementation is completely different:
http://www.sencha.com/learn/legacy/Manual:Utilities:Function#createDelegate
Even though Dojo and jQuery implementations don't extend
Function.prototype they follow Prototype's implementation with the
exception that they also allow passing a string instead of a function
and jQuery adds a `guid` property to the bound function.
http://dojotoolkit.org/api/dojo.hitch
http://api.jquery.com/jQuery.proxy/#example-1
Prototype 1.7's Function#bind (which overwrites native bind too) isn't
as ES5 compliant as it could be because its bound function doesn't
behave correctly when called as part of a new expression.
function Foo(a,b,c) {
this.a = a;
this.b = b;
this.c = c;
}
var Bound = Foo.bind({}, 1, 2);
var b = new Bound(3);
console.log(Object.keys(b)); // [], but should be ['a', 'b', 'c']
console.log(b.c) // undefined, but should be 3
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
What's the reasoning behind the extra restrictions in [[CanPut]]?
So I was digging through repairES5.js
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#1427
and noticed that:
var a = Object.freeze({ 'x': 1 });
var b = Object.create(a);
b.x = 2;
b.x; // should still be 1
Then I dug into spec and noticed:
http://es5.github.com/#x8.12.4
so `b.x` remains 1 because the property 'x' of its [[Prototype]] is
writable: false.
Ok, so why all of that when you could simply do:
var b = Object.create(a, {
'x': {
'configurable': true,
'enumerable': true,
'writable': true,
'value': 2
}
});
or
Object.defineProperty(b, 'x', {
'configurable': true,
'enumerable': true,
'writable': true,
'value': 2
});
b.x; // 2
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
The cross-browser differences of {}.hasOwnProperty('__proto__') and
{}.__proto__.hasOwnProperty('__proto__') are interesting and need to
be ironed out.
As for the issue of using objects as dictionaries you can simply
prefix keys with some unique value, `var uid = 'uid' + (+new Date);`,
and then access entries like `dict[uid + key]`. This will allow value
lookups to work correctly cross-browser regardless of ES5+ or
__proto__ support.
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
In GWT, we did exactly this prefix operation, and we found GC became a problem on IE because of it, as each lookup or store in the map creates a new garbage string. GWT has larger problems if key prefixes are giving it perf grief (even in older IE). - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
Actually, there's no reason for the prefix or suffix to be random or unguessable or Right, I recently tweeted an example using a zero-width non-breaking space and at the time suggested it could be something as simple as using an underscore. https://twitter.com/#!/jdalton/status/140296487694381056 https://github.com/jdalton/fusejs/blob/2365ede5ac51c97f12b3e31fc6f16dff45552e92/src/lang/hash.js#L149-155 - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.extends (was Re: traits feedback)
On Fri, Oct 7, 2011 at 10:17 AM, Jake Verbaten rayn...@gmail.com wrote: Object.extend is the only method I shim on every es5 project, so +1 However arguments like library X is would break are stupid, remember es6 is an opt-in so backwards compat with existing code be damned. No U! My concern came from seeing ES5 additions like Function#bind partially hindered because spec'ed behavior isn't covered by most shims/existing lib implementations. For example using the bound function's behavior with the `new` operator is inconsistent with most third party code/shims. But since it's opt-in yes you can muck with dev expectations and change the behavior of additions that have existed for 6yrs or so :D As for the functionality, it should just be an n-ary function which extends the first object with all the _own_ properties of the other n-1 objects. If keys clash give right precedence. I've used this flavor of extends too (minus the own properties part). whether key clashes favour left or right isnt important. whether the return value is undefined or the first object isnt important. Yap but chaining FTW. please dont try arguments from authority like bad library X copies over enumerable properties from the prototype chain so we should too. If that part is opt-in then sure go for implementing it better than existing libs but why not push for the monocle operator? -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.extends (was Re: traits feedback)
From: Andrew Dupont mozi...@andrewdupont.net
JJB has it mostly right. When Sam wrote Object.extend (which was originally
Object.prototype.extend), it didn't use hasOwnProperty; my guess is that Sam
didn't know about it, because most of us were JavaScript amateurs back in the
day, including myself. When I joined the project over a year later, I
remember discussing this problem and discovering that Safari 2.0 didn't
support hasOwnProperty.
For an example of creating a workaround for lack of hasOwnProperty see:
https://github.com/bestiejs/spotlight.js/blob/master/spotlight.js#L189
That, plus the hazard of changing implementation behavior, led us to leave
things as they were. If I were writing Prototype's Object.extend from
scratch, I'd definitely want it to copy own properties only.
MooTools also has an Object.extend() with a bonus that it tries to
avoid IE bugs with for..in over shadowed Object.prototype properties.
I've used similar private `extend()` functions that mimic the
Prototype/MooTools behavior and remember in at least one of my
projects running into problems when attempting to make extend() only
iterate over own properties.
Anyway, I'm in favor of standardizing Object.extend in ES6, but in a way that
considers only own properties (including private names, if so desired). I
don't think ES6 should copy the exact behavior of Prototype's (flawed)
version of Object.extend. Whether that takes the form of a method named
Object.extend or a .{ operator? well, that's less important to me, but my
vote is for the former.
The former, Object.extend, will be hard to add if it is to only
iterate over `own` properties, as I think it should, because
Prototype/MooTools and others add their own Object.extend, without
checking if the method exists, paving any existing method with their
own implementation. This will create inconsistencies between
pages/third-party code that use Prototype/MooTools and those that
don't. Introducing an operator has the advantage of not being
overwritten/mucked-with and allows for shorter/fluid syntax.
I 3 monocle operator!
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ in Annex B (was: Re: Sep 27 meeting notes)
It is a standard (de-facto), we were just talking about making a non-mandatory normative spec for it. That does carry some weight but not much more than the de-facto standard, IMHO. A non-mandatory normative spec, like that of String#substr (even though JScript implementation is diff) would rock! Current implementations of __proto__ differ on how they handle `null` values. I believe FF won't allow it to be set again once it is nulled while others allow it to be set again. - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
double checking if window.eval(…) is an indirect call to eval().
So I have read the section (and the notes associated with it) over what a direct call to eval is: http://es5.github.com/#x15.1.2.1.1 http://dev.w3.org/html5/spec/Overview.html#script-s-global-object A direct call to the eval function is one that is expressed as a CallExpression that meets the following two conditions: The Reference that is the result of evaluating the MemberExpression in the CallExpression has an environment record as its base value and its reference name is eval. The result of calling the abstract operation GetValue with that Reference as the argument is the standard built-in function defined in 15.1.2.1. But I am still a little unsure if `window.eval(…)` is a direct call or not. I have heard `window.eval()` is an indirect call but wanted to make sure. I see it as call expressionmember expression window.eval/member expression (…) /call expression Wouldn't the result of evaluating the MemberExpression `window.eval` have global's environment record as its base and a reference name of `eval`? Is `window.eval(..)` a direct call to eval? Thanks, -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: double checking if window.eval(…) is an indirect call to eval().
@Oliver Hunt I have a vague recollection that *monkey treats global object.eval(..) as a direct eval? Firefox 4 will execute `window.eval(….)` as in the global execution context but will still allow access to variables that are accessible from the execution context of where `window.eval` was called. You can see this in the jQuery bug I mentioned here: https://twitter.com/#!/jdalton/status/70778564617838592 - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Where in spec does it explain why setting the value of an existing property will change its [[Enumerable]] attribute.
Hiya,
Array.prototype.reduce which is by default { [[Writable]]: true,
[[Enumerable]]: false, [[Configurable]]: true } will change to
[[Enumerable]]: true when:
Array.prototype.reduce = function() {…};
Why do you think this should change [[Enmerable]] to true??
Oh, I *didn't say* I think it should. I said we were trying to explain
an existing behavior we were seeing.
Would you all help point to where this is defined in spec?
It isn't. Simply assigning a new value to an already existing own data
property isn't supposed to change any attributes.
Awesome! That was our conclusion too. It was late Kit and I missed
trying it in other implementations (instead we dug into spec because
we thought it was odd). It turns out V8 (Chrome, Node.js) has a bug
that will make non-enumerable properties enumerable by assigning a new
value as in my previous snippet :O
Thanks again,
JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Where in spec does it explain why setting the value of an existing property will change its [[Enumerable]] attribute.
Awesome! That was our conclusion too. It was late Kit and I missed trying it in other implementations (instead we dug into spec because we thought it was odd). It turns out V8 (Chrome, Node.js) has a bug that will make non-enumerable properties enumerable by assigning a new value as in my previous snippet :O I suspect that this only applies to builtin properties on objects, as I think JSC has a similar issue. You are right. V8 doesn't have this problem for object properties created with `Object.defineProperty` and friends. Also right again, JSC does appear to have a similar issue (tested Safari 2.0.0 - WebKit Nightly) Speaking for JSC (but i wouldn't be surprised if V8 did something similar) we will delay the creation of the majority of builtin properties until they're actually used, eg. until you actually access Array.prototype.reduce we won't reify the property. A side effect of this is that when you simply assign to the property we skip reification, and so the property attributes are the same as you would get if you were creating a new property. A simple test would be to see if Array.prototype.reduce; Array.prototype.reduce = ... Results in the correct behaviour. Though it does avoid the bug in JSC, accessing the property before setting it doesn't affect V8 on built-ins as it will still bug. I have made a simple test file here: http://dl.dropbox.com/u/513327/enum_bug.html Another odd thing is that V8 uses the `Array#push` internally for `Object.defineProperties`. I noticed that if I set `Array.prototype.push = 1;` using `Object.defineProperties(…)` would error complaining about `push` not being a function. - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 54, Issue 29
On Mon, Aug 15, 2011 at 8:42 PM, es-discuss-requ...@mozilla.org wrote: Send es-discuss mailing list submissions to es-discuss@mozilla.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.mozilla.org/listinfo/es-discuss or, via email, send a message with subject or body 'help' to es-discuss-requ...@mozilla.org You can reach the person managing the list at es-discuss-ow...@mozilla.org When replying, please edit your Subject line so it is more specific than Re: Contents of es-discuss digest... Today's Topics: 1. Re: Re: On ES.next features prototype implementations in web browsers (Douglas Crockford) 2. Re: A directive to solve the JavaScript arithmetic precision issue (David Bruant) 3. Re: A directive to solve the JavaScript arithmetic precision issue (Brendan Eich) 4. Re: May the defineProperty method of a proxy handler throw a TypeError? (Cameron McCormack) 5. Re: On ES.next features prototype implementations in web browsers (Brendan Eich) 6. Re: A Narcissus implementation of various object literal extensions (Zachary Carter) -- Message: 1 Date: Mon, 15 Aug 2011 13:21:23 -0700 From: Douglas Crockford doug...@crockford.com To: es-discuss@mozilla.org Subject: Re: Re: On ES.next features prototype implementations in web browsers Message-ID: 4e497fc3.5090...@crockford.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11:59 AM, Brendan Eich wrote: We've been extending JS in SpiderMonkey forever. Had we not, it's hard to say what would have happened. One anecote: getters and setters were something I added over a decade ago, such that when Firefox took enough share from IE that by 2005, the live.com properties (live maps, I believe) used getters and setters on Firefox to emulate IE's non-standard DOM. This caused very rapid reverse-engineering of getters and setters in Safari and Opera. I'm not relating this to tell a story with a clean moral. Some of this was accidental, but much of it was game theory. Had we hidden getters and setters behind a flag, I'm not sure what Microsoft's web developers would have done. Probably use an Ajax library that did not require IE DOM quirk emulation I think you are probably right. They could have done a good thing, but getters and setters gave them a license to continue doing the bad thing. So ultimately they took a lot longer to finally adopt jQuery. -- Message: 2 Date: Mon, 15 Aug 2011 22:58:43 +0200 From: David Bruant david.bru...@labri.fr To: Brendan Eich bren...@mozilla.com Cc: es-discuss es-discuss@mozilla.org Subject: Re: A directive to solve the JavaScript arithmetic precision issue Message-ID: 4e498883.80...@labri.fr Content-Type: text/plain; charset=ISO-8859-1 Le 15/08/2011 21:33, Brendan Eich a ?crit : On Aug 15, 2011, at 10:33 AM, David Bruant wrote: I don't know if it has been proposed already, but what about a directive? Code could look like: -- use precise arithmetic; // choose any other name you'd like here var a = 0.1 + 0.2; // 0.3 // FINALLY! -- What number format should be used? I have no expertise whatsoever in that domain, so i'll let people who do talk. In his talks, Douglas Crockford mentions that the fact that JS has one number type is a good thing, so, maybe that choosing a unique replacement should be the best thing. Alternatively, the directive could be parametrized with number formats (use number IEEE XYZ). You will not get premature standardization past TC39 on this front. Our agreement when decimal missed ES3.1 in 2008 fall (the Kona meeting) was to work on value types so that new numeric types could be implemented in-language. That's an interesting piece of information. If I understand it correctly, it would imply that the expression 0.1+0.2 will never be equal to 0.3 in a JavaScript program (even with any sort of opt-in (@type versionning, directive, pragma...)). The best thing i can think of is wrapping my numbers to create values out of them. So, wrap(0.1)+wrap(0.2) can be equal to 0.3. (Tell me if there is a part i misunderstand or forget) Consequently, in order to have accurate arithmetic, i can: - wrap by hand my numbers (which doesn't scale well if i want to apply it to current JS files) - use a compiler/transpiler to wrap numbers automatically. But it would be hard to tell automatically which numbers should be wrapped and which should not. Wrapping all numbers could have annoying performance issues. - use some combining approach (interactive tool, heuristics...) Also, from what i understand, typeof( wrap(0.1)+wrap(0.2) ) could not be number. A directive may not solve every problem caused by numeric types, but it would solve the problem of making current code work with precise arithmetic at a small
Function#bind [[HasInstance]] question.
Sorry about the last empty reply, GMail got ahead of itself :D
So Chrome and Firefox disagree on their Function#bind implementation.
http://es5.github.com/#x15.3.4.5.2
http://es5.github.com/#x15.3.4.5.3
~~~ js
function Bar() {
return 1;
}
var bound = Bar.bind({});
new bound instanceof bound; // Firefox reports `true`, Chrome `false`
(I think Chrome is right)
new bound instance of Bar; // Firefox and Chrome report `true`
~~~
The test262 doesn't appear to cover this case.
What is the correct result of `new bound instance of bound;` and why?
-JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function#bind [[HasInstance]] question.
Thanks Luke, Your explanation made it click. I was going to file a bug report, but found it already existed (from 2010 k). http://code.google.com/p/v8/issues/detail?id=793 -JDD On Tue, Aug 16, 2011 at 12:12 PM, Luke Hoban lu...@microsoft.com wrote: My interpretation of these spec sections: (new bound) instanceof bound = (new Bar()) instanceof bound // bind's Construct defers to the targetFunction and ignores bound thisValue = bound.[[HasInstance]](new Bar()) // meaning of instanceof = Bar.[[HasInstance]](new Bar()) // bind's HasInstance defers to the targetFunction = true // normal HasInstance Similarly for 'new bound instanceof Bar'. IE and Firefox both appear to agree with this result. Luke ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Where in spec does it explain why setting the value of an existing property will change its [[Enumerable]] attribute.
So @kitcambridge and I were talking spec and started trying to find in
spec something that explains why something like:
Array.prototype.reduce which is by default { [[Writable]]: true,
[[Enumerable]]: false, [[Configurable]]: true } will change to
[[Enumerable]]: true when:
Array.prototype.reduce = function() {…};
So far we have struck out.
In ES3 we found 8.6.2.2 [[Put]](P, V)
http://bclary.com/2004/11/07/#a-8.6.2.2
and its step 4:
4. Set the value of the property to V. The attributes of the property
are not changed.
And then we dug into ES5.1 and its [[Put]]
http://es5.github.com/#x8.12.5
and its step step 3a which leads to [[DefineOwnProperty]] with a Desc
of {[[Value]]: V} and its step 10b to 12, then 13.
but couldn't find where it stated changing the [[Enumerable]] attribute.
Would you all help point to where this is defined in spec?
Thanks,
JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Wanted: standard Array function to append an array's
@Jeff In reply to https://mail.mozilla.org/pipermail/es-discuss/2011-July/016124.html, which engines have problems with `firstArray.push.apply(firstArray, secondArray)` ? Shouldn't a bug report be filed for the specific JS engine or the spec be clarified on the subject (String.fromCharCode too) instead of adding another method to Array.prototype? -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Table 23 - Tags for classified native objects, typos in ES6 draft
Just a heads-up that the tag values for [[IsRegExp]] and [[IsError]], in Table 23 - Tags for classified native objects, are not correct. http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Pure win: Array.from and Array.of
I dig Array.from, and have manually made sugar for that in my projects. Array.of is something I have also wanted though I had been struggling with a name for it. Until now if I wanted to avoid setting the array length I would do something like ns.Array.from([23]), but Array.of is nice too ;) - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Standardizing __proto__
The __proto__ property has been around for ~13yrs and is now a de facto standard supported by Chrome, Firefox, Safari, Opera, Adobe Flash, Adobe AIR, Rhino, Ringo, Narwhal, Node.js. It's available on desktops, mobile phones, tablets, and even eReaders. The __proto__ property is a powerful language feature that cannot be reproduced through any existing part of the language. Current proposals like, http://wiki.ecmascript.org/doku.php?id=strawman:array_create, are too limiting, (it's useful for more than just arrays) and don't cover the full functionality/flexibility of __proto__. I propose making it official by beginning the process of standardizing __proto__ or some addition of equal utility. More info: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/proto https://bugzilla.mozilla.org/show_bug.cgi?id=642500 - John-David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
@Oliver That said your examples environments that support it is slightly misleading as there's only a few JS engines being used between them: Caraken (Opera person is this correct?), JavaScriptCore, SpiderMonkey and V8. AIR uses webkit so pulls in JSC, and presumably ActionScript as well, although ActionScript is not really an ES engine so i'm unsure if it counts to this discussion. The point is __proto__ has a very long history and is supported by more browsers/environments than it's not. @Mike Shaver For other possible uses please check out: http://msdn.microsoft.com/en-us/scriptjunkie/gg278167 https://github.com/jdalton/fusebox#readme and follow the bug report. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
For symmetry with Object.create, you might want Boolean.create, Date.create and so forth, but that's still initialization-time, and TBH I would be surprised if there were actually many collisions between libraries that augment those prototypes. In the Script Junkie article I cover a few examples of collisions with Function.prototype's and problems with Array.prototype. Date.create, Function.create and the like clutters the API. I would be for a more generic Object.setPrototypeOf() addition. http://es5.github.com/#x15.2.3.2 and I can't really find anything other than Fuse that uses it on the web today PrototypeJS uses it. I think you can also achieve what you want with Harmony proxies, so you'll have that option in the next edition of ES. I don't know. It would need to preserve internal [[Class]] as __proto__. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
Array create seems like a good interface for that particular use case even if the general solution that encompasses things other than Array ended up being something different. Limiting it to Array.create seems shortsighted. It's useful for Strings, Numbers, RegExp, and others. Adding Array.create() would mean eventually adding .create() to the others (which is better than nothing), but a more generic solution would be ideal. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
There is a general problem of supporting creation of special behavior objects Yes, I think it would be ok to assume that the spirit of __proto__ can be achieved by a solution that sets the [[Prototype]] at creation. This would possibly help with WebKit's security concerns while not sacrificing functionality. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
I think Oliver's original formulation is more correct, but regardless this really would have to be specified using ES5 pseudo code. This is along the path of what I was calling a generalized solution to the problem and as such I think it needs deeper/longer consideration to be sure we have it right. I think a single argument Array.create is safer if we are looking for something that could be immediately implemented in order to start phasing out __proto__. Having Array.create wouldn't stop also providing a more general solution such as the one below. As a dev who actually uses __proto__ as a fallback for sandboxed Arrays, I can tell you that Array.create() is **not** a quick, suitable solution. I support more than Array like String, RegExp, Function, Number, and Boolean. I would stress, as it seems you keep circling back to Array.create(), that Array.create() is not a fitting replacement for __proto__. Not even in the short term. I can see Oliver's proposal totally fitting __proto__'s use case, so I would +1 his Object.subclass() over Array.create(). It would be great if solutions like Oliver's Object.subclass() were discussed in the next meeting. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
Did I miss new, mutating uses of __proto__ in PrototypeJS? Nope, nothing new in PrototypeJS. Mutating use of __proto__ can be found in https://github.com/jdalton/fusejs as 1 of the 3 techniques used. The __proto__ fork is only being used by Safari (because of a loong time iframe bug https://bugs.webkit.org/show_bug.cgi?id=25079) as well as possible server side usage. I think it's good to start looking into alternatives to __proto__ and I would love an official standardized alternative :D Also very happy you wrote that this will not be a quick change. -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
I think I understand what you doing here, especially for Array but I don't
think it really addresses my Number, Boolean, String question.
Instances of those instances usually aren't created via explicit constructor
calls but by implicit conversions that the ES5 spec. hardwires
to the appropriate built-in prototype object. In the most common cases for
es5, say string.concat(foo) a string object isn't even created for the
property lookup.
I'm skeptical that many developers actually would code:
fs.String(stirng).concat(foo) rather thanstring.concat(foo). How much
actual usage do you see of the Number, Boolean, and String cases?
Ya, some people have that reaction at first, but after use it's not
bad. Most of the time you create a string or value once then pass
around the variable.
Because these sandboxed natives chain, usage is natural. As such
fuse.String(...).split(' ') produces a sandboxed Array so you go from
1 sandboxed native to another without hassle.
Same goes for fuse.Array(1,2,3).join() - a sandboxed String value.
Generics are also supported fuse.String.concat(str, other) so you can
pass in regular natives too.
PrototypeJS and other libs use wrapper/utilities for strings, DOM
elements, arrays, ... so using fuse.String() is just as easy as say
$w().
By using the framework it becomes second nature to assume, for
example, fuse(...).getAttribute(..) returns a sandboxed String value.
-JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
But AIUI the point of sandboxing is to keep different libraries from stepping on each other's toes, and AFAICT such libraries use literals (string, array, object and regexp) quite liberally. Sandbox natives are used so FuseJS plays well with others while allowing the extension/modification of it's own set of natives. It's not about fix existing lib compatibility. In Prototype all 4 are used. But they also extended global natives which causes conflicts. For example ExtJS adds Function#delay but so does PrototypeJS, and when used together they cause a JS errors. OR when MooTools/Prototype added Array#toJSON which broke native JSON for over a year and caused conflicts with YUI. In jQuery all 4 are used and passing in a String object where a string primitive is expected will fail because of explicit typeof checks. Again not for jQuery. They have their own hurdles with an overly generic jQuery function, where attempting to check for isPlainObject is necessarily. If you *do* control the code in question, you can just write your code to use a namespace (Object.prototype.ns.method(), Extending the Object.prototype is a compatibility nightmare and extending natives causes third party script headaches. Sandboxed natives behave like natives and have the correct internal [[Class]] values so you can extend/customize without polluting the ones on the global. You can even create more than one of say the Array constructor as with fuse.Array and fuse.dom.NodeList (also an Array constructor but with DOM methods on it's prototype) And this **is** possible, in part, because of __proto__. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
It was a compatibility nightmare when people didn't namespace, and when you couldn't make non-enumerable properties. Using a namespace for additions to the prototype chain and using ES5's defineProperty to keep those additions from affecting enumeration behaviour seems like it overcomes those, at least to me. Unfortunately not all browsers/environments support ES5 defineProperty, and not all third party code, widgets, ads, and js libs guard against extensions in their for-in loops. -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
But to get back to shaver's point: you are requiring a stylized, non-standard, popular-library-incompatible dialect of JS to be used from the start to work inside FuseJS's sandboxes, IIUC. Right? Mike was getting OT onto the specifics and merits of sandboxed natives/FuseJS. I was originally answering Allen's prompt for examples of other non Array uses for __proto__. That's ok, not criticizing per se. Just noting it's yet another dialect. There are many such, some with translators that can handle the wrapping, even for primitives and literals, for you. Non that provide the flexibility of extending prototypes of natives directly without the risk of conflict and none that **work** in browsers/environments from Safari 2.0.0 through IE9. Harmony is not about standardizing whatever hacks you needed to make your dialect work. Thanks for the `hacks` comment. It's about core language features that complete and correct (by extension if not incompatible change) the incomplete and sometimes messy core language, even as of ES5. I and others find __proto__ useful and gave a good use-case as prompted. I am ok with __proto__'s eventual removal but as you stated earlier there should be a replacement for use-cases. The __proto__ property **is** a de facto standard and should be standardized in some form to ensure compatibility, consistency, and security. As mentioned before Array.create() is not enough, something like Object.subclass() as previously proposed would be flexible for most use-cases and eliminate some of the perf/security concerns implementers have. -JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array#indexOf and Array#lastIndexOf question
I noticed that most Array methods perform [[HasProperty]] checks on the index values. Array#indexOf and Array#lastIndexOf do not. Firefox 3, Safari 4, Chrome 2 all seem to check [[HasProperty]] for Array#indexOf and lastIndexOf. Is this an oversight on the draft or did the browser vendors miss something ? - John-David Dalton ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Could this be removed from Array#concat.
I think that under 15.4.4.4 Array.prototype.concat 5 - b. - iii - 3 - a. Call ToString(n). could be removed as it is performed in c. - John-David Dalton ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Pretty function expression names
I just wanted to point out http://trac.webkit.org/changeset/42478. The changeset states: This change adds the displayName property to functions, which when set overrides the normal name when appearing in the console. - John-David Dalton ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.indexOf use of SameValue()
In the ECMA 5 RC spec I noticed that 15.4.4.14 Array.prototype.indexOf (and lastIndexOf) make use of the SameValue operation. The spec states that (9.12) SameValue will return true If Type(x) is Undefined or Null. Would this not cause an issue with 9c of the Array.prototype.indexOf spec. c. If SameValue(searchElement,elementK) is true, return k.. [1,2,null].indexOf(null) - SameValue(null, 1) - true, return 0. var undef; [1,2,undef].indexOf(undef) - SameValue(undefined, 1) - true, return 0. - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
