i kown why ToNumber(undefined) is NaN and ToNumber(null) is 0? so undefined == undefined is true,undefined == null is true, but undefined >= undefined,undefined <= undefined, undefined>=null and undefined <= null is false. all this cause by ToNumber(undefined) is NaN and ToNumber(null) is 0.
On Wed, Apr 29, 2009 at 3:01 AM, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Indexed string pseudo properties and for-in, was RE: Comments > on April ES5 final draft standard tc39-2009-025 (Allen > Wirfs-Brock) > 2. Re: Indexed string pseudo properties and for-in, was RE: > Comments on April ES5 final draft standard tc39-2009-025 > (Mark S. Miller) > 3. RE: Indexed string pseudo properties and for-in, was RE: > Comments on April ES5 final draft standard tc39-2009-025 > (Allen Wirfs-Brock) > 4. Array.prototype.indexOf use of SameValue() (John-David Dalton) > 5. RE: Array.prototype.indexOf use of SameValue() (Allen Wirfs-Brock) > 6. Re: Array.prototype.indexOf use of SameValue() (Mark S. Miller) > > > ---------- Forwarded message ---------- > From: Allen Wirfs-Brock <[email protected]> > To: "Mark S. Miller" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected] > > > Date: Mon, 27 Apr 2009 17:28:14 -0700 > Subject: Indexed string pseudo properties and for-in, was RE: Comments on > April ES5 final draft standard tc39-2009-025 > As currently specified, they are to be enumerated by for-in. This is > intentional and I believe we discussed it at some past TC-39 meeting. If we > are treating the string characters as indexible readonly properties then > for-in-ing over them seems like a perfectly reasonable thing to do. This is > one of the advantages of using [[GetOwnProperty]] in this manner rather than > trying to support direct string indexing using some other specification > mechanism -- they just naturally integrate into property access anywhere it > occurs in the specification. > > >-----Original Message----- > >From: [email protected] [mailto:es5-discuss- > >[email protected]] On Behalf Of Mark S. Miller > ... > > > >15.5.5.2 [[GetOwnProperty]] ( P ) > > > >> 9. Return a Property Descriptor { [[Value]]: resultStr, > >[[Enumerable]]: true, [[Writable]]: false, [[Configurable]]: false } > > > >Since these numeric pseudo-properties are not enumerated by for-in > >loops, we should describe them as non-enumerable. > > > > > > > ---------- Forwarded message ---------- > From: "Mark S. Miller" <[email protected]> > To: Allen Wirfs-Brock <[email protected]> > Date: Mon, 27 Apr 2009 18:59:14 -0700 > Subject: Re: Indexed string pseudo properties and for-in, was RE: Comments > on April ES5 final draft standard tc39-2009-025 > On Mon, Apr 27, 2009 at 5:28 PM, Allen Wirfs-Brock > <[email protected]> wrote: > > As currently specified, they are to be enumerated by for-in. This is > intentional and I believe we discussed it at some past TC-39 meeting. If we > are treating the string characters as indexible readonly properties then > for-in-ing over them seems like a perfectly reasonable thing to do. This is > one of the advantages of using [[GetOwnProperty]] in this manner rather than > trying to support direct string indexing using some other specification > mechanism -- they just naturally integrate into property access anywhere it > occurs in the specification. > > > I'm happy with that, so long as it's consistent with the definition of > for-in. However, the only relevant text I could find in for-in is > > > Let P be the name of the next property of obj whose [[Enumerable]] > attribute is true. If there is no such property, return (normal, V, empty). > > Since these indexes are not actually properties of strings, this text > is insufficient. > > -- > Cheers, > --MarkM > > > > ---------- Forwarded message ---------- > From: Allen Wirfs-Brock <[email protected]> > To: "Mark S. Miller" <[email protected]> > Date: Tue, 28 Apr 2009 09:23:13 -0700 > Subject: RE: Indexed string pseudo properties and for-in, was RE: Comments > on April ES5 final draft standard tc39-2009-025 > You may be right, that an additional note is warranted. However, being in > a contentious mood I'll also argue that these are indeed properties of > string objects. If [[GetOwnProperty]](P) says P is a property that then it > really is one. In other words: > P is the name of a own property of O iff O.[[GetOwnProperty]](P) is > not undefined > that is pretty much exactly how Object.prototype.hasOwnProperty(V) is > defined. > > The hole in the spec. seems to be that a few places (for-in, Object.keys, > etc.) we use informal language to enumerate an object's properties. We > probably need a more formal definition that incorporates the above rule. > > Allen > > >-----Original Message----- > >From: Mark S. Miller [mailto:[email protected]] > >Sent: Monday, April 27, 2009 6:59 PM > >To: Allen Wirfs-Brock > >Cc: [email protected]; [email protected] > >Subject: Re: Indexed string pseudo properties and for-in, was RE: > >Comments on April ES5 final draft standard tc39-2009-025 > > > ... > >I'm happy with that, so long as it's consistent with the definition of > >for-in. However, the only relevant text I could find in for-in is > > > >> Let P be the name of the next property of obj whose [[Enumerable]] > >attribute is true. If there is no such property, return (normal, V, > >empty). > > > >Since these indexes are not actually properties of strings, this text > >is insufficient. > > > >-- > > Cheers, > > --MarkM > > > > > ---------- Forwarded message ---------- > From: John-David Dalton <[email protected]> > To: [email protected] > Date: Tue, 28 Apr 2009 13:34:49 -0500 > Subject: 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 > > > > ---------- Forwarded message ---------- > From: Allen Wirfs-Brock <[email protected]> > To: John-David Dalton <[email protected]>, " > [email protected]" <[email protected]> > Date: Tue, 28 Apr 2009 11:48:17 -0700 > Subject: RE: Array.prototype.indexOf use of SameValue() > The first step of SameValue is > 1. If Type(x) is different from Type(y), return false. > > undefined, null, and number are 3 distinct types so SameValue(null,1) -> > false and SameValue(undefined,1) -> false > > > >-----Original Message----- > >From: [email protected] [mailto:es-discuss- > >[email protected]] On Behalf Of John-David Dalton > >Sent: Tuesday, April 28, 2009 11:35 AM > >To: [email protected] > >Subject: 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 > >[email protected] > >https://mail.mozilla.org/listinfo/es-discuss > > > > > ---------- Forwarded message ---------- > From: "Mark S. Miller" <[email protected]> > To: John-David Dalton <[email protected]> > Date: Tue, 28 Apr 2009 11:49:33 -0700 > Subject: Re: Array.prototype.indexOf use of SameValue() > On Tue, Apr 28, 2009 at 11:34 AM, John-David Dalton > <[email protected]> wrote: > > 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. > > The steps which say these (steps 2 & 3) occur after step 1: > > 1. If Type(x) is different from Type(y), return false. > 2. If Type(x) is Undefined, return true. > 3. If Type(x) is Null, return true. > > so steps 2 & 3 only apply if Type(x) is the same as Type(y). > > > 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. > > No, because Type(null) is Null and Type(1) is Number; so step 1 will > return false. > > > > var undef; > > [1,2,undef].indexOf(undef) -> SameValue(undefined, 1) -> true, return 0. > > > > - JDD > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- > Cheers, > --MarkM > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
