es-discuss Digest, Vol 26, Issue 13
welefen
welefen at gmail.com
Wed Apr 29 02:09:14 PDT 2009
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, <es-discuss-request at mozilla.org> wrote:
> Send es-discuss mailing list submissions to
> es-discuss at 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-request at mozilla.org
>
> You can reach the person managing the list at
> es-discuss-owner at 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. 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 <Allen.Wirfs-Brock at microsoft.com>
> To: "Mark S. Miller" <erights at google.com>, "es5-discuss at mozilla.org" <
> es5-discuss at mozilla.org>, "es-discuss at mozilla.org" <es-discuss at mozilla.org
> >
> 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: es5-discuss-bounces at mozilla.org [mailto:es5-discuss-
> >bounces at mozilla.org] 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" <erights at google.com>
> To: Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>
> 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
> <Allen.Wirfs-Brock at microsoft.com> 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 <Allen.Wirfs-Brock at microsoft.com>
> To: "Mark S. Miller" <erights at google.com>
> 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:erights at google.com]
> >Sent: Monday, April 27, 2009 6:59 PM
> >To: Allen Wirfs-Brock
> >Cc: es5-discuss at mozilla.org; es-discuss at mozilla.org
> >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 <john.david.dalton at gmail.com>
> To: es-discuss at mozilla.org
> 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 <Allen.Wirfs-Brock at microsoft.com>
> To: John-David Dalton <john.david.dalton at gmail.com>, "
> es-discuss at mozilla.org" <es-discuss at mozilla.org>
> 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: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> >bounces at mozilla.org] On Behalf Of John-David Dalton
> >Sent: Tuesday, April 28, 2009 11:35 AM
> >To: es-discuss at mozilla.org
> >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
> >es-discuss at mozilla.org
> >https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> ---------- Forwarded message ----------
> From: "Mark S. Miller" <erights at google.com>
> To: John-David Dalton <john.david.dalton at gmail.com>
> 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
> <john.david.dalton at gmail.com> 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Cheers,
> --MarkM
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090429/2556ab7d/attachment.html>
More information about the es-discuss
mailing list