Re: [[Get]] and GetValue can return Reference Type
Thanks, I filed this issue at
https://bugs.ecmascript.org/show_bug.cgi?id=387
Regards,
Yusuke Suzuki
On Thu, Jun 14, 2012 at 12:47 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
could you file this as a bug at bugs.ecmascript.org
I want to make sure it isn't forgotten if nobody else responds.
Allen
On Jun 11, 2012, at 11:03 PM, Yusuke Suzuki wrote:
This issue is derived from Esprima issue 81
http://code.google.com/p/esprima/issues/detail?id=81
Hello everyone,
According to the ECMA262 5.1th, [[Call]] of host object may return
Reference Type.
So, all values using raw [[Call]] result may be Reference Type.
For example, [[Get]] may return Reference Type if *getter* is a host
object that [[Call]] returns Reference Type.
http://ecma-international.org/ecma-262/5.1/#sec-8.12.3
As the result, GetValue may return Reference Type because that use result
value of [[Get]]
http://ecma-international.org/ecma-262/5.1/#sec-8.7.1
And, for example, if we define getter of object, getter function is host
object that [[Call]] return Reference Type,
(10, obj.getter)
returns Reference type, so,
(10, obj.getter) = 10;
is valid because GetValue is performed, but GetValue result is also
Reference Type.
In the ECMA262 5.1th, GetValue is assumed that doesn't return Reference
Type, for exmaple,
var obj = {
get v() {
// this v function is host object and returns Reference;
// we can define this v using host object and defineProperty
return Reference;
}
};
And,
typeof obj.v
Then, typeof should treat Reference Type also, but in 11.4.3, Reference
Type is not considered.
http://ecma-international.org/ecma-262/5.1/#sec-11.4.3
I think this is a bug of spec and GetValue and [[Get]] should not return
Reference type, is it right?
To fix this, I think following 3 way are good.
1. perform GetValue on [[Call]] result in the spec
2. re-define [[Get]] and GetValue can return Reference Type. This
needs to re-define all the spec part using [[Get]], GetValue and others
3. remove feature that [[Call]] can return Reference Type
Because all modern engines don't consider that [[Call]] result is
Reference and this feature makes big performance-regression, personally I
think 3 is better.
Regards,
Yusuke Suzuki
___
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
[NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
Hello everybody, I am not sure about the status of this subject but I find quite inconsistent the fact we cannot trust Array#indexOf when it comes to NaN ... I am updating my es6-collections shim accordingly with what Paul Millr said: my shim does not consider NaN as a valid key, being unable to find a match through indexOf, so each NaN key will result into a new one for both Map and Set ( broken WeakMap too ) I wonder if in the next future Array#indexOf will use internally Object.is to compare values or if I have to use my own function to loop over all values and do this kind of comparison. Any thought on this will be appreciated and apologies if this has been discussed already ( so a quick answer on how it's going to be would be more than enough ) Best Regards, Andrea Giammarchi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Would some like Object.inspect(myObj) be useful?
Was just wondering if something like *Object.inspect(myObj) *would give all the attributes of that particular object. -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
On 14 June 2012 10:42, Hemanth H.M hemanth...@gmail.com wrote: Was just wondering if something like *Object.inspect(myObj) *would give all the attributes of that particular object. Is there a proposal or strawman you're referring to? I'm not immediately seeing it, but I'm still new here. PrototypeJS has an Object.inspecthttp://api.prototypejs.org/language/Object/inspect/function, but I don't see a strawman suggesting it join the specification. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Aurora VS Canary Map and Set
Hi again,
here few inconsistencies I have found with latest version, for Mac, of
these two dev/channel browsers.
Map#set(key, value)
Aurora: Map#set() returns undefined in any case. After, if value is
undefined/void 0, Map#has(key) will return true and Map#get(key) will
return undefined/void 0
Canary: Map#set() returns the set value in any case. After, if value is
undefined/void 0, Map#has(key) will return false. The key will be removed
indeed so the get(key) will return undefined.
My Take:
returning the value with Map#set may become handier than returning always
undefined, in a JavaScript like code style.
deleting implicitly the key makes no sense at all. Map has so much focus
on edge cases such NaN and +0 VS -0 but an explicit value as undefined is
cannot be assigned as desired value BUT it can be used as key ?!?? Implicit
key removal goes against Map#delete(key) logic too since this method
returns true or false accordingly if the key was there or not.
As Summary
*anything value Map#set(anything key, anything value) looks the most
concrete/meaningful signature without implicit Map#delete(key) calls ...
please clarify if what I am saying makes sense and if both Aurora and
Canary will follow this behavior, thanks.
Set#delete(keyAsValue)
Aurora: consistent behavior with Map#delete(key) ... the returned value
is a boolean, true or false if the key was there
Canary: inconsistent behavior with Map#delete(key) ... Set#delete(
keyAsValue) returns undefined and I really do not understand why this is
happening. My tests fails with surprise here while these where green before
... bad choice, imho, I'd like to understand why is that.
Set#add(keyAsValue)
both Aurora and Canary returns undefined here and I find this a bit
inconsistent too. I see Set#add as a simplified Map#set where keyAsValue
could be returned.
If your argument is that Set#add(keyAsValue) has different purpose than
Map#set I wonder why the behavior is not consistent with Map#delete(key)
where at least, Set#add(keyAsValue) could return true or false accordingly
if the keyAsValue was there or not.
if (Set#add(generic)) {
// first time generic has been set
} else {
// generic was there already
}
My Take:
while the returning boolean could be considered superfluous, since it
could be implemented in Set#delete(generic) or simply passing through the
Set#has(generic) check, returning the added generic value would be more
than helpful for many common tasks.
mySingleSet.add(myGenericObject).methodCallOnAdd(/*args*/);
Thanks for any sort of clarification.
Best Regards,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
No there is no proposal of that I'm aware of in Strawman, just asking the group if it's useful? On Thu, Jun 14, 2012 at 3:23 PM, T.J. Crowder t...@crowdersoftware.comwrote: On 14 June 2012 10:42, Hemanth H.M hemanth...@gmail.com wrote: Was just wondering if something like *Object.inspect(myObj) *would give all the attributes of that particular object. Is there a proposal or strawman you're referring to? I'm not immediately seeing it, but I'm still new here. PrototypeJS has an Object.inspecthttp://api.prototypejs.org/language/Object/inspect/function, but I don't see a strawman suggesting it join the specification. -- T.J. -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
Le 14/06/2012 11:42, Hemanth H.M a écrit : Was just wondering if something like *Object.inspect(myObj) *would give all the attributes of that particular object. In ES5, there are Object.getOwnPropertyNames as well as Object.getOwnPropertyDescriptor. These are the lowest-level constructs you need to do any introspection, I think. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
On 14 June 2012 11:07, Hemanth H.M hemanth...@gmail.com wrote: No there is no proposal of that I'm aware of in Strawman, just asking the group if it's useful? I can't speak for the group, but I think you'd need to explain it a lot more. :-) What would it return? How does it relate to the existing reflect_api harmony proposalhttp://wiki.ecmascript.org/doku.php?id=harmony:reflect_api? How does it differ from something built using Object.keys or for..in? Does it include non-enumerable properties? When you say attributes, do you mean properties or something else? Not harshing, just trying to understand what you're raising. (Side note: The convention on the list seems to be quote-first and comment below the quote [as above], rather than the other way around [which is gmail's default].) -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
Please replace your use of indexOf in your collection implementations instead. If indexOf is more efficient than one written in JS using Object.is, then use the fast one when the argument is anything other than NaN, 0, and -0. On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Hello everybody, I am not sure about the status of this subject but I find quite inconsistent the fact we cannot trust Array#indexOf when it comes to NaN ... I am updating my es6-collections shim accordingly with what Paul Millr said: my shim does not consider NaN as a valid key, being unable to find a match through indexOf, so each NaN key will result into a new one for both Map and Set ( broken WeakMap too ) I wonder if in the next future Array#indexOf will use internally Object.is to compare values or if I have to use my own function to loop over all values and do this kind of comparison. Any thought on this will be appreciated and apologies if this has been discussed already ( so a quick answer on how it's going to be would be more than enough ) Best Regards, Andrea Giammarchi ___ 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: Aurora VS Canary Map and Set
On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Hi again,
here few inconsistencies I have found with latest version, for Mac, of
these two dev/channel browsers.
Map#set(key, value)
Aurora: Map#set() returns undefined in any case. After, if value is
undefined/void 0, Map#has(key) will return true and Map#get(key) will return
undefined/void 0
Canary: Map#set() returns the set value in any case. After, if value is
undefined/void 0, Map#has(key) will return false. The key will be removed
indeed so the get(key) will return undefined.
My Take:
returning the value with Map#set may become handier than returning always
undefined, in a JavaScript like code style.
deleting implicitly the key makes no sense at all. Map has so much focus
on edge cases such NaN and +0 VS -0 but an explicit value as undefined is
cannot be assigned as desired value BUT it can be used as key ?!?? Implicit
key removal goes against Map#delete(key) logic too since this method returns
true or false accordingly if the key was there or not.
As Summary
*anything value Map#set(anything key, anything value) looks the most
concrete/meaningful signature without implicit Map#delete(key) calls ...
please clarify if what I am saying makes sense and if both Aurora and Canary
will follow this behavior, thanks.
I'd like to remind everyone that there's a draft spec at
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets.
This is likely to change on the way to becoming official. But by this
spec, the behavior you report for Aurora is correct and Canary is
buggy. I'd appreciate it if you would file a bug report. Thanks.
Set#delete(keyAsValue)
Aurora: consistent behavior with Map#delete(key) ... the returned value is
a boolean, true or false if the key was there
Canary: inconsistent behavior with Map#delete(key) ...
Set#delete(keyAsValue) returns undefined and I really do not understand why
this is happening. My tests fails with surprise here while these where green
before ... bad choice, imho, I'd like to understand why is that.
By the draft spec, again Aurora is correct and Canary is buggy.
Set#add(keyAsValue)
both Aurora and Canary returns undefined here and I find this a bit
inconsistent too. I see Set#add as a simplified Map#set where keyAsValue
could be returned.
Returning undefined is consistent both with Aurora's behavior for
Map#set and with the draft spec for Map#set.
If your argument is that Set#add(keyAsValue) has different purpose than
Map#set I wonder why the behavior is not consistent with Map#delete(key)
where at least, Set#add(keyAsValue) could return true or false accordingly
if the keyAsValue was there or not.
This may be a better design -- I can make arguments both ways and we
should have that argument. But that's the way it's currently (draft)
speced, so for the sake of browser agreement, we should follow the
draft spec until we agree on something else.
OTOH, in alphas, betas, canarys, nightlys, or whatever prior to
official release, it's also good to experiment with changes one is
thinking of proposing -- in order to gain experience first. I doubt
that is what is happening here, but if it is, we should not discourage
it.
if (Set#add(generic)) {
// first time generic has been set
} else {
// generic was there already
}
My Take:
while the returning boolean could be considered superfluous, since it
could be implemented in Set#delete(generic) or simply passing through the
Set#has(generic) check, returning the added generic value would be more than
helpful for many common tasks.
mySingleSet.add(myGenericObject).methodCallOnAdd(/*args*/);
Thanks for any sort of clarification.
Best Regards,
Andrea Giammarchi
___
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: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
This is basically what I am doing except I find Array#indexOf as it is pointless ... or better, something that should be fixed in the next version of ECMAScript. Right now I am feature detecting the inconsistent behavior ... but a feature detection that will never possibly return true is also pointless ... thanks in any case :-) br On Thu, Jun 14, 2012 at 12:41 PM, Mark S. Miller erig...@google.com wrote: Please replace your use of indexOf in your collection implementations instead. If indexOf is more efficient than one written in JS using Object.is, then use the fast one when the argument is anything other than NaN, 0, and -0. On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Hello everybody, I am not sure about the status of this subject but I find quite inconsistent the fact we cannot trust Array#indexOf when it comes to NaN ... I am updating my es6-collections shim accordingly with what Paul Millr said: my shim does not consider NaN as a valid key, being unable to find a match through indexOf, so each NaN key will result into a new one for both Map and Set ( broken WeakMap too ) I wonder if in the next future Array#indexOf will use internally Object.is to compare values or if I have to use my own function to loop over all values and do this kind of comparison. Any thought on this will be appreciated and apologies if this has been discussed already ( so a quick answer on how it's going to be would be more than enough ) Best Regards, Andrea Giammarchi ___ 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: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
just in case ... this is my internal function
// var is = Object.is || properShim
// var indexOf = [].indexOf || shortShim
// var i;
function betterIndexOf(value) {
if (value != value || value === 0) {
for (i = this.length; i-- !is(this[i], value););
} else {
i = indexOf.call(this, value);
}
return i;
}
maybe somebody else should implement something similar to avoid N
Object.is(a, b) checks within the loop ...
cheers
On Thu, Jun 14, 2012 at 1:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This is basically what I am doing except I find Array#indexOf as it is
pointless ... or better, something that should be fixed in the next version
of ECMAScript.
Right now I am feature detecting the inconsistent behavior ... but a
feature detection that will never possibly return true is also pointless
... thanks in any case :-)
br
On Thu, Jun 14, 2012 at 12:41 PM, Mark S. Miller erig...@google.comwrote:
Please replace your use of indexOf in your collection implementations
instead. If indexOf is more efficient than one written in JS using
Object.is, then use the fast one when the argument is anything other
than NaN, 0, and -0.
On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Hello everybody,
I am not sure about the status of this subject but I find quite
inconsistent the fact we cannot trust Array#indexOf when it comes to
NaN ...
I am updating my es6-collections shim accordingly with what Paul Millr
said:
my shim does not consider NaN as a valid key, being unable to find a
match
through indexOf, so each NaN key will result into a new one for both
Map and
Set ( broken WeakMap too )
I wonder if in the next future Array#indexOf will use internally
Object.is
to compare values or if I have to use my own function to loop over all
values and do this kind of comparison.
Any thought on this will be appreciated and apologies if this has been
discussed already ( so a quick answer on how it's going to be would be
more than enough )
Best Regards,
Andrea Giammarchi
___
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: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
Andrea Giammarchi wrote:
just in case ... this is my internal function
// var is = Object.is || properShim
// var indexOf = [].indexOf || shortShim
// var i;
function betterIndexOf(value) {
if (value != value || value === 0) {
for (i = this.length; i-- !is(this[i], value););
I always has the impression that indexOf is firstIndexOf not
lastIndexOf... sometimes it matters.
Herby
} else {
i = indexOf.call(this, value);
}
return i;
}
maybe somebody else should implement something similar to avoid N
Object.is(a, b) checks within the loop ...
cheers
On Thu, Jun 14, 2012 at 1:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
This is basically what I am doing except I find Array#indexOf as it
is pointless ... or better, something that should be fixed in the
next version of ECMAScript.
Right now I am feature detecting the inconsistent behavior ... but a
feature detection that will never possibly return true is also
pointless ... thanks in any case :-)
br
On Thu, Jun 14, 2012 at 12:41 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
Please replace your use of indexOf in your collection
implementations
instead. If indexOf is more efficient than one written in JS using
Object.is, then use the fast one when the argument is anything other
than NaN, 0, and -0.
On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com wrote:
Hello everybody,
I am not sure about the status of this subject but I find
quite
inconsistent the fact we cannot trust Array#indexOf when it
comes to NaN ...
I am updating my es6-collections shim accordingly with what
Paul Millr said:
my shim does not consider NaN as a valid key, being unable to
find a match
through indexOf, so each NaN key will result into a new one
for both Map and
Set ( broken WeakMap too )
I wonder if in the next future Array#indexOf will use
internally Object.is
to compare values or if I have to use my own function to loop
over all
values and do this kind of comparison.
Any thought on this will be appreciated and apologies if this
has been
discussed already ( so a quick answer on how it's going to
be would be
more than enough )
Best Regards,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@mozilla.org mailto: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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Aurora VS Canary Map and Set
To summarize, Aurora is correct everywhere while Canary isn't ... and
there's nothing is specs about removing the key if the value is undefined.
I take Aurora as the right one then, thanks a lot!
On Thu, Jun 14, 2012 at 12:56 PM, Mark S. Miller erig...@google.com wrote:
On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Hi again,
here few inconsistencies I have found with latest version, for Mac, of
these two dev/channel browsers.
Map#set(key, value)
Aurora: Map#set() returns undefined in any case. After, if value is
undefined/void 0, Map#has(key) will return true and Map#get(key) will
return
undefined/void 0
Canary: Map#set() returns the set value in any case. After, if value is
undefined/void 0, Map#has(key) will return false. The key will be removed
indeed so the get(key) will return undefined.
My Take:
returning the value with Map#set may become handier than returning
always
undefined, in a JavaScript like code style.
deleting implicitly the key makes no sense at all. Map has so much
focus
on edge cases such NaN and +0 VS -0 but an explicit value as undefined is
cannot be assigned as desired value BUT it can be used as key ?!??
Implicit
key removal goes against Map#delete(key) logic too since this method
returns
true or false accordingly if the key was there or not.
As Summary
*anything value Map#set(anything key, anything value) looks the most
concrete/meaningful signature without implicit Map#delete(key) calls ...
please clarify if what I am saying makes sense and if both Aurora and
Canary
will follow this behavior, thanks.
I'd like to remind everyone that there's a draft spec at
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets.
This is likely to change on the way to becoming official. But by this
spec, the behavior you report for Aurora is correct and Canary is
buggy. I'd appreciate it if you would file a bug report. Thanks.
Set#delete(keyAsValue)
Aurora: consistent behavior with Map#delete(key) ... the returned
value is
a boolean, true or false if the key was there
Canary: inconsistent behavior with Map#delete(key) ...
Set#delete(keyAsValue) returns undefined and I really do not understand
why
this is happening. My tests fails with surprise here while these where
green
before ... bad choice, imho, I'd like to understand why is that.
By the draft spec, again Aurora is correct and Canary is buggy.
Set#add(keyAsValue)
both Aurora and Canary returns undefined here and I find this a bit
inconsistent too. I see Set#add as a simplified Map#set where keyAsValue
could be returned.
Returning undefined is consistent both with Aurora's behavior for
Map#set and with the draft spec for Map#set.
If your argument is that Set#add(keyAsValue) has different purpose than
Map#set I wonder why the behavior is not consistent with Map#delete(key)
where at least, Set#add(keyAsValue) could return true or false
accordingly
if the keyAsValue was there or not.
This may be a better design -- I can make arguments both ways and we
should have that argument. But that's the way it's currently (draft)
speced, so for the sake of browser agreement, we should follow the
draft spec until we agree on something else.
OTOH, in alphas, betas, canarys, nightlys, or whatever prior to
official release, it's also good to experiment with changes one is
thinking of proposing -- in order to gain experience first. I doubt
that is what is happening here, but if it is, we should not discourage
it.
if (Set#add(generic)) {
// first time generic has been set
} else {
// generic was there already
}
My Take:
while the returning boolean could be considered superfluous, since it
could be implemented in Set#delete(generic) or simply passing through the
Set#has(generic) check, returning the added generic value would be more
than
helpful for many common tasks.
mySingleSet.add(myGenericObject).methodCallOnAdd(/*args*/);
Thanks for any sort of clarification.
Best Regards,
Andrea Giammarchi
___
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: Aurora VS Canary Map and Set
Le 14/06/2012 12:56, Mark S. Miller a écrit : On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Hi again, here few inconsistencies I have found with latest version, for Mac, of these two dev/channel browsers. Map#set(key, value) Aurora: Map#set() returns undefined in any case. After, if value is undefined/void 0, Map#has(key) will return true and Map#get(key) will return undefined/void 0 Canary: Map#set() returns the set value in any case. After, if value is undefined/void 0, Map#has(key) will return false. The key will be removed indeed so the get(key) will return undefined. My Take: returning the value with Map#set may become handier than returning always undefined, in a JavaScript like code style. deleting implicitly the key makes no sense at all. Map has so much focus on edge cases such NaN and +0 VS -0 but an explicit value as undefined is cannot be assigned as desired value BUT it can be used as key ?!?? Implicit key removal goes against Map#delete(key) logic too since this method returns true or false accordingly if the key was there or not. As Summary *anything value Map#set(anything key, anything value) looks the most concrete/meaningful signature without implicit Map#delete(key) calls ... please clarify if what I am saying makes sense and if both Aurora and Canary will follow this behavior, thanks. I'd like to remind everyone that there's a draft spec at http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets. This is likely to change on the way to becoming official. But by this spec, the behavior you report for Aurora is correct and Canary is buggy. I'd appreciate it if you would file a bug report. Thanks. Seeing these inconsistencies for a feature draft spec-ed in relatively unambiguous pseudo-ECMAScript code puzzles me. For relevant features, would it make sense to ship tests alongside with the spec? Implementors do write tests before shipping a feature. Could they agree to systematically contribute tests to test262 now that it exists? I don't think it would be that big of an additional burden but it would definitely benefit everyone a lot apparently! David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
On Thu, Jun 14, 2012 at 5:42 AM, Hemanth H.M hemanth...@gmail.com wrote: Was just wondering if something like *Object.inspect(myObj) *would give all the attributes of that particular object. What would this function return? There's already an Object.keyshttps://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/keyssfunction - does that do what you wanted? That's in ES5. - Russ -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ 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: Aurora VS Canary Map and Set
I have written tests already so if I have to change few things and push to test262 just let me know, thanks. br On Thu, Jun 14, 2012 at 2:46 PM, David Bruant bruan...@gmail.com wrote: Le 14/06/2012 12:56, Mark S. Miller a écrit : On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Hi again, here few inconsistencies I have found with latest version, for Mac, of these two dev/channel browsers. Map#set(key, value) Aurora: Map#set() returns undefined in any case. After, if value is undefined/void 0, Map#has(key) will return true and Map#get(key) will return undefined/void 0 Canary: Map#set() returns the set value in any case. After, if value is undefined/void 0, Map#has(key) will return false. The key will be removed indeed so the get(key) will return undefined. My Take: returning the value with Map#set may become handier than returning always undefined, in a JavaScript like code style. deleting implicitly the key makes no sense at all. Map has so much focus on edge cases such NaN and +0 VS -0 but an explicit value as undefined is cannot be assigned as desired value BUT it can be used as key ?!?? Implicit key removal goes against Map#delete(key) logic too since this method returns true or false accordingly if the key was there or not. As Summary *anything value Map#set(anything key, anything value) looks the most concrete/meaningful signature without implicit Map#delete(key) calls ... please clarify if what I am saying makes sense and if both Aurora and Canary will follow this behavior, thanks. I'd like to remind everyone that there's a draft spec at http://wiki.ecmascript.org/**doku.php?id=harmony:simple_**maps_and_setshttp://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets . This is likely to change on the way to becoming official. But by this spec, the behavior you report for Aurora is correct and Canary is buggy. I'd appreciate it if you would file a bug report. Thanks. Seeing these inconsistencies for a feature draft spec-ed in relatively unambiguous pseudo-ECMAScript code puzzles me. For relevant features, would it make sense to ship tests alongside with the spec? Implementors do write tests before shipping a feature. Could they agree to systematically contribute tests to test262 now that it exists? I don't think it would be that big of an additional burden but it would definitely benefit everyone a lot apparently! David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
it doesn't in my case ... arrays are sandboxed so none can access them
and set twice the same value ;-)
anyway, that was a proof of concept, not a fully implemented indexOf with
strict comparison, apologies I should have specified that.
br
On Thu, Jun 14, 2012 at 2:25 PM, Herby Vojčík he...@mailbox.sk wrote:
Andrea Giammarchi wrote:
just in case ... this is my internal function
// var is = Object.is || properShim
// var indexOf = [].indexOf || shortShim
// var i;
function betterIndexOf(value) {
if (value != value || value === 0) {
for (i = this.length; i-- !is(this[i], value););
I always has the impression that indexOf is firstIndexOf not
lastIndexOf... sometimes it matters.
Herby
} else {
i = indexOf.call(this, value);
}
return i;
}
maybe somebody else should implement something similar to avoid N
Object.is(a, b) checks within the loop ...
cheers
On Thu, Jun 14, 2012 at 1:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com
mailto:andrea.giammarchi@**gmail.comandrea.giammar...@gmail.com
wrote:
This is basically what I am doing except I find Array#indexOf as it
is pointless ... or better, something that should be fixed in the
next version of ECMAScript.
Right now I am feature detecting the inconsistent behavior ... but a
feature detection that will never possibly return true is also
pointless ... thanks in any case :-)
br
On Thu, Jun 14, 2012 at 12:41 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
Please replace your use of indexOf in your collection
implementations
instead. If indexOf is more efficient than one written in JS using
Object.is, then use the fast one when the argument is anything
other
than NaN, 0, and -0.
On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com
mailto:andrea.giammarchi@**gmail.comandrea.giammar...@gmail.com
wrote:
Hello everybody,
I am not sure about the status of this subject but I find
quite
inconsistent the fact we cannot trust Array#indexOf when it
comes to NaN ...
I am updating my es6-collections shim accordingly with what
Paul Millr said:
my shim does not consider NaN as a valid key, being unable to
find a match
through indexOf, so each NaN key will result into a new one
for both Map and
Set ( broken WeakMap too )
I wonder if in the next future Array#indexOf will use
internally Object.is
to compare values or if I have to use my own function to loop
over all
values and do this kind of comparison.
Any thought on this will be appreciated and apologies if this
has been
discussed already ( so a quick answer on how it's going to
be would be
more than enough )
Best Regards,
Andrea Giammarchi
__**_
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org**
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
--**--**
__**_
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: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
I don't think an array is the right solution for this particular problem though. The performance penalty is too much to make it worth it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
My two sense. In my experience (large applications, rather than tight
libraries), distinguishing between null and undefined is the exception, not
the rule. When it is distinguished, as often as not the author would be
more correct in either including null or making an property existence
check (foo in bar) rather than an explicit check for undefined.
On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users
immediately tested o.p != null to existing-check. There was even some
confusion where missing array elements in primordial JS evaluated to null
not undefined. Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist,
though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-**optimization of storing null rather
than using delete doesn't argue for defaulting based on LHS value in {null,
undefined}.
Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or
biology. Not just Homer Simpson Life is just a bunch of things that
happen randomness, mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null
and undefined are confusingly similar, in part due to being ==. This is
true, but I still do not see actual use-cases where null is passed into
code that uses || to select a default value. Would love to see such
real-world code.
/be
__**_
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: Would some like Object.inspect(myObj) be useful?
The inspect module provides functions for introspecting on live objects and their source code. On Thu, Jun 14, 2012 at 6:21 PM, Russell Leggett russell.legg...@gmail.comwrote: On Thu, Jun 14, 2012 at 5:42 AM, Hemanth H.M hemanth...@gmail.com wrote: Was just wondering if something like *Object.inspect(myObj) *would give all the attributes of that particular object. What would this function return? There's already an Object.keyshttps://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/keyssfunction - does that do what you wanted? That's in ES5. - Russ -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Aurora VS Canary Map and Set
Mark S. Miller wrote: OTOH, in alphas, betas, canarys, nightlys, or whatever prior to official release, it's also good to experiment with changes one is thinking of proposing -- in order to gain experience first. I doubt that is what is happening here, but if it is, we should not discourage it. We should discuss first, though. The way to proceed is not for a browser vendor (especially one with market power to abuse, not saying this is any particular vendor! shifts over time) try stuff out that no peer has ever heard proposed in the strawman section of the wiki, even in an open issues or two-competing-straw-designs setting. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
In our experience writing large apps, the distinction is useful. Undefined
means I forgot to do something (e.g. set a property or pass an argument); null
means I tried to get something but it didn't exist.
Very roughly, it becomes undefined = caller error outside of my control, null =
my error and I should use the API more correctly.
On Jun 14, 2012, at 11:27, John Lenz
concavel...@gmail.commailto:concavel...@gmail.com wrote:
My two sense. In my experience (large applications, rather than tight
libraries), distinguishing between null and undefined is the exception, not the
rule. When it is distinguished, as often as not the author would be more
correct in either including null or making an property existence check (foo in
bar) rather than an explicit check for undefined.
On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich
bren...@mozilla.orgmailto:bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users
immediately tested o.p != null to existing-check. There was even some confusion
where missing array elements in primordial JS evaluated to null not undefined.
Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist,
though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-optimization of storing null rather than
using delete doesn't argue for defaulting based on LHS value in {null,
undefined}.
Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or biology.
Not just Homer Simpson Life is just a bunch of things that happen randomness,
mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null and
undefined are confusingly similar, in part due to being ==. This is true, but I
still do not see actual use-cases where null is passed into code that uses ||
to select a default value. Would love to see such real-world code.
/be
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto: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: ||= is much needed?
Confusion: at no point has the
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator
strawman removed the infix operator originally proposed as ?? and
currently spelled ?: -- everyone agrees on having both OP and OP=,
whatever the spelling of OP.
I agree on reflection with Wes and others who've objected that A ?: B
has the simplest interpretation as A ? A : B and therefore should not be
used for anything like (A !== undefined) ? A : B or (A != null) ? A : B.
I noted this as an open issue but I'm almost ready to flip the strawman
back to ?? and ??=. Comments on syntax?
On semantics: CoffeeScript's use of != null to equate null and undefined
matches some users' habits, and helps to conceal the awkward fact of two
bottom-types in JS (@jashkenas just averred that was the goal). But such
concealment can never be perfect and other users will either want to
distinguish, or (what is more worrisome) will accidentally distinguish
(e.g. with !==) null from undefined.
If only we didn't have both null and undefined! I blame Java (after
myself, of course). But we're stuck with both and we have to make the
best of this situation.
I still don't see a lot of intentional use of null to mean undefined,
e.g. as a no argument, please default value passed into APIs. But null
or any falsy value would work fine for APIs whose implementations
default using ||, so it is possible null is used widely by convention,
and I just haven't seen it.
Whatever we do, we should do the same for parameter default values.
CoffeeScript is consistent in equating null and undefined and triggering
parameter defaulting as if by its ?= assignment op:
f = (x, y=1, z=2) - console.log(x, y, z)
f(0, null, undefined)
generates
f = function(x, y, z) {
if (y == null) {
y = 1;
}
if (z == null) {
z = 2;
}
return console.log(x, y, z);
};
f(0, null, void 0);
We could certainly do worse than to pave this cowpath.
/be
David Herman wrote:
On Jun 12, 2012, at 10:52 PM, Brendan Eich wrote:
People don't default on the caller side (at the callsite) much, in my experience. Dave may be seeing other sources, but it's extremely rare in my experience to see
foo(arg1 || callers_idea_of_default_arg1_value);
I'm sure it's more rare than the assignment form, but that's partly because the assignment form is needed to make up for lack of pdv's.
whereas we all see
function foo(a, b, c) {
a = a || default_a;
b.x = b.x || default_b_x;
b.y = b.y || default_b_y;
c.z = function (w) {
// long body here
}
...
}
Well, you wouldn't argue against having || in the language. Yes, I know it serves other roles as well. But only providing the assignment form strikes me as over-specialization. Operators are a straightforward generalization of assignments. When you specialize the syntax to provide an assignment form only, you force people to create temporary variables when they aren't needed. Compound expressions are good things!
And why break the pattern of compound assignments being based on binary operators? Why should ?= or ??= be different from +=, -=, *=, /=, %=,=,=,=,=, |=, ^=? It just seems like a pointless restriction.
Dave
___
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: Would some like Object.inspect(myObj) be useful?
On Jun 14, 2012, at 9:49 AM, Hemanth H.M wrote: The inspect module provides functions for introspecting on live objects and their source code. As do many of the ES5 methods in Object.*. It's not clear what you mean by source code in this context. If you want to have discussion about an idea like this you have to provide a much more complete description of what you have in mind. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
var info = { name: Hemanth, url: http://h3manth.com/;, location :
Earth, get : function() {} };
Object.keys(info)
[name, url, location, get]
Now, it's not clear about the 'type' of the keys; name is a String, where
as get is a function.
Compared to something like inspect module in python that give o/p like :
('__delslice__', method-wrapper '__delslice__' of list object at
0x1005252d8)
On Thu, Jun 14, 2012 at 10:41 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Jun 14, 2012, at 9:49 AM, Hemanth H.M wrote:
The inspect module provides functions for introspecting on live objects
and their source code.
As do many of the ES5 methods in Object.*. It's not clear what you mean
by source code in this context.
If you want to have discussion about an idea like this you have to provide
a much more complete description of what you have in mind.
Allen
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
Hemanth H.M wrote:
var info = { name: Hemanth, url: http://h3manth.com/;, location :
Earth, get : function() {} };
Object.keys(info)
[name, url, location, get]
Now, it's not clear about the 'type' of the keys; name is a String,
where as get is a function.
Compared to something like inspect module in python that give o/p like :
('__delslice__', method-wrapper '__delslice__' of list object at
0x1005252d8)
Python's repr convention is missed in JS, but instead of trying to force
everything into a standard string representation, how about just
building on ES5 (already mailed to you, sharing with list here):
js o = {p:1, q:2, get r(){return 3}}
({p:1, q:2, get r () {return 3;}})
js function inspect(o) {
var a = [];
Object.getOwnPropertyNames(o).forEach(function (k) {
a.push(Object.getOwnPropertyDescriptor(o, k));
});
return a;
}
js d = inspect(o)
[{configurable:true, enumerable:true, value:1, writable:true},
{configurable:true, enumerable:true, value:2, writable:true},
{configurable:true, enumerable:true, get:(function () {return 3;}),
set:(void 0)}]
ES5 has plural Object.defineProperties for defining more than one
property on an object, and of course Object.create that defines all the
properties on a new object from a descriptor-map. But it doesn't have
anything like this inspect. We could add such an
Object.getPropertyDescriptors API, for sure.
/be
On Thu, Jun 14, 2012 at 10:41 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
On Jun 14, 2012, at 9:49 AM, Hemanth H.M wrote:
The inspect module provides functions for introspecting on live
objects and their source code.
As do many of the ES5 methods in Object.*. It's not clear what
you mean by source code in this context.
If you want to have discussion about an idea like this you have to
provide a much more complete description of what you have in mind.
Allen
--
/'I am what I am because of who we all are'/
h3manth.com http://www.h3manth.com
/-- Hemanth HM/
___
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: Would some like Object.inspect(myObj) be useful?
WOW! Thanks a ton for the clarification. On Thu, Jun 14, 2012 at 10:52 PM, Brendan Eich bren...@mozilla.com wrote: ES5 has plural Object.defineProperties for defining more than one property on an object, and of course Object.create that defines all the properties on a new object from a descriptor-map. But it doesn't have anything like this inspect. We could add such an Object.getPropertyDescriptors API, for sure. -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
Brendan Eich wrote: ES5 has plural Object.defineProperties for defining more than one property on an object, and of course Object.create that defines all the properties on a new object from a descriptor-map. But it doesn't have anything like this inspect. We could add such an Object.getPropertyDescriptors API, for sure. Object.getOwnPropertyDescriptors, I should have written. Own, *sigh*. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 14, 2012, at 10:10 AM, Brendan Eich wrote:
On semantics: CoffeeScript's use of != null to equate null and undefined
matches some users' habits, and helps to conceal the awkward fact of two
bottom-types in JS (@jashkenas just averred that was the goal). But such
concealment can never be perfect and other users will either want to
distinguish, or (what is more worrisome) will accidentally distinguish (e.g.
with !==) null from undefined.
If only we didn't have both null and undefined! I blame Java (after myself,
of course). But we're stuck with both and we have to make the best of this
situation.
+1 (except Java doesn't have the equivalent of undefined as a manifest value)
I still don't see a lot of intentional use of null to mean undefined, e.g. as
a no argument, please default value passed into APIs. But null or any falsy
value would work fine for APIs whose implementations default using ||, so it
is possible null is used widely by convention, and I just haven't seen it.
Whatever we do, we should do the same for parameter default values.
CoffeeScript is consistent in equating null and undefined and triggering
parameter defaulting as if by its ?= assignment op:
I think treating null as not provided, use the default in parameters is a bad
thing that would be going down the path of concealment that is rejected above.
While some (many??) people use null and undefined interchangeably, other are no
doubt using them closer to the original intention (uninitialized/missing value
vs. no object). To cause null to trigger parameter (and destructuring)
default values wound break that current valid usage pattern.
While I'm less than enthusiastic about explicitly provided undefined values
triggering default value usages, I don't think it is particularly harmful. I
think treating null equivalently would be.
f = (x, y=1, z=2) - console.log(x, y, z)
f(0, null, undefined)
generates
f = function(x, y, z) {
if (y == null) {
y = 1;
}
if (z == null) {
z = 2;
}
return console.log(x, y, z);
};
f(0, null, void 0);
We could certainly do worse than to pave this cowpath.
sure, for example, by having any falsy value trigger default value usage. But
just because there are worse things doesn't make the a good idea.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
T.J. Crowder wrote: On 14 June 2012 18:10, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: I agree on reflection with Wes and others who've objected that A ?: B has the simplest interpretation as A ? A : B and therefore should not be used for anything like (A !== undefined) ? A : B or (A != null) ? A : B. I noted this as an open issue but I'm almost ready to flip the strawman back to ?? and ??=. Comments on syntax? Do people see sufficient value in a second ternary operator that uses the same semantics for what's a non-value? E.g.: a = b ?? c : d; meaning a = b !== undefined ? c : d; No, too thin. Also preempts ?? as an infix operator, which has been proposed for quite a while as the default operator. If people *don't* see sufficient value in the second ternary (and the use cases are pretty limited), ?? and ??= are great. Ship 'em. Not in ES6, but I'm working on the strawman to get them into Harmony, so they can be prototyped, user-tested, and standardized in due course. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
Allen Wirfs-Brock wrote:
On Jun 14, 2012, at 10:22 AM, Brendan Eich wrote:
Hemanth H.M wrote:
var info = { name: Hemanth, url: http://h3manth.com/;, location : Earth,
get : function() {} };
Object.keys(info)
[name, url, location, get]
Now, it's not clear about the 'type' of the keys; name is a String, where as
get is a function.
Compared to something like inspect module in python that give o/p like :
('__delslice__',method-wrapper '__delslice__' of list object at 0x1005252d8)
Python's repr convention is missed in JS, but instead of trying to force
everything into a standard string representation, how about just building on
ES5 (already mailed to you, sharing with list here):
js o = {p:1, q:2, get r(){return 3}}
({p:1, q:2, get r () {return 3;}})
js function inspect(o) {
var a = [];
Object.getOwnPropertyNames(o).forEach(function (k) {
a.push(Object.getOwnPropertyDescriptor(o, k));
You probably want to make the above line:
a.[k] = Object.getOwnPropertyDescriptor(o,k}
Confusing .[ typo there :-P.
This should give you a descriptor that can be passed back into
Object.defineProperties
Also initialize a to { }.
Let me redo the REPL session:
js o = {p:1, q:2, get r(){return 3}}
({p:1, q:2, get r () {return 3;}})
js function inspect(o) {
var r = {};
Object.getOwnPropertyNames(o).forEach(function (k) {
r[k] = Object.getOwnPropertyDescriptor(o, k);
});
return r;
}
js d = inspect(o)
({p:{configurable:true, enumerable:true, value:1, writable:true},
q:{configurable:true, enumerable:true, value:2, writable:true},
r:{configurable:true, enumerable:true, get:(function () {return 3;}),
set:(void 0)}})
Thanks. Any reason this wasn't included in ES5 that you recall?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Would some like Object.inspect(myObj) be useful?
On Jun 14, 2012, at 10:52 AM, Brendan Eich wrote: ... Thanks. Any reason this wasn't included in ES5 that you recall? Minimalism. Object.* wasn't intended to be a comprehensive reflection library, just a set of essential primitives that could be used tin building such. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Allen Wirfs-Brock wrote:
While I'm less than enthusiastic about explicitly provided undefined values
triggering default value usages, I don't think it is particularly harmful. I
think treating null equivalently would be.
Noted, but you have not responded to the argument, made by Sam
Tobin-Hochstadt based on Racket experience, Tab Atkins in Common Lisp,
and others, that failing to treat explicit undefined as a defaulting
trigger creates an anti-modular, combinatorial explosion when wrapping
and delegating. This is the sole reason undefined (or undefined and
null, separate issue) as defaulting trigger is proposed. Please respond
to it directly.
f = (x, y=1, z=2) - console.log(x, y, z)
f(0, null, undefined)
generates
f = function(x, y, z) {
if (y == null) {
y = 1;
}
if (z == null) {
z = 2;
}
return console.log(x, y, z);
};
f(0, null, void 0);
We could certainly do worse than to pave this cowpath.
sure, for example, by having any falsy value trigger default value usage. But
just because there are worse things doesn't make the a good idea.
That's a reductio ad absurdum, nothing to do with why I wrote what I wrote.
We have a problem with || indeed. The question is whether the solution
should equate null and undefined. CoffeeScript chose the
conceal-the-difference path and it has users. The users who want null to
be distinct from undefined are neither CoffeeScript users, nor || users
(in their defaulting code). They must be doing === undefined test. That
is rare too (not quite as rare as passing null instead of undefined as
intentional default trigger in my experience).
What is your reason for preferring === undefined over == null, since we
have a dilemma and users often use an even looser (falsy, viz ||) test
than == null, but some use == null and others use === undefined, for the
defaulting trigger?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
While I'm less than enthusiastic about explicitly provided undefined
values triggering default value usages, I don't think it is
particularly harmful. I think treating null equivalently would be.
Noted, but you have not responded to the argument, made by Sam
Tobin-Hochstadt based on Racket experience, Tab Atkins in Common Lisp,
and others, that failing to treat explicit undefined as a defaulting
trigger creates an anti-modular, combinatorial explosion when wrapping
and delegating. This is the sole reason undefined (or undefined and
null, separate issue) as defaulting trigger is proposed. Please respond
to it directly.
f = (x, y=1, z=2) - console.log(x, y, z)
f(0, null, undefined)
generates
f = function(x, y, z) {
if (y == null) {
y = 1;
}
if (z == null) {
z = 2;
}
return console.log(x, y, z);
};
f(0, null, void 0);
We could certainly do worse than to pave this cowpath.
sure, for example, by having any falsy value trigger default value
usage. But just because there are worse things doesn't make the a good
idea.
That's a reductio ad absurdum, nothing to do with why I wrote what I wrote.
We have a problem with || indeed. The question is whether the solution
should equate null and undefined. CoffeeScript chose the
conceal-the-difference path and it has users. The users who want null to
be distinct from undefined are neither CoffeeScript users, nor || users
(in their defaulting code). They must be doing === undefined test. That
is rare too (not quite as rare as passing null instead of undefined as
intentional default trigger in my experience).
What is your reason for preferring === undefined over == null, since we
have a dilemma and users often use an even looser (falsy, viz ||) test
than == null, but some use == null and others use === undefined, for the
defaulting trigger?
If I can add my own, I use || (because it's short, and if (foo) pattern
desensitivised me), but if there would be an operator for undefined,
I'll switch to use it immediately (I always see it as undefined, knowing
I do sin when using ||).
Btw, |if(foo)| also needs replacement in that case, though if ?? will be
there, |if (foo??true)| (or |if (foo??1)|) would serve the case well.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Herby Vojčík wrote:
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
While I'm less than enthusiastic about explicitly provided undefined
values triggering default value usages, I don't think it is
particularly harmful. I think treating null equivalently would be.
Noted, but you have not responded to the argument, made by Sam
Tobin-Hochstadt based on Racket experience, Tab Atkins in Common Lisp,
and others, that failing to treat explicit undefined as a defaulting
trigger creates an anti-modular, combinatorial explosion when wrapping
and delegating. This is the sole reason undefined (or undefined and
null, separate issue) as defaulting trigger is proposed. Please respond
to it directly.
f = (x, y=1, z=2) - console.log(x, y, z)
f(0, null, undefined)
generates
f = function(x, y, z) {
if (y == null) {
y = 1;
}
if (z == null) {
z = 2;
}
return console.log(x, y, z);
};
f(0, null, void 0);
We could certainly do worse than to pave this cowpath.
sure, for example, by having any falsy value trigger default value
usage. But just because there are worse things doesn't make the a good
idea.
That's a reductio ad absurdum, nothing to do with why I wrote what I
wrote.
We have a problem with || indeed. The question is whether the solution
should equate null and undefined. CoffeeScript chose the
conceal-the-difference path and it has users. The users who want null to
be distinct from undefined are neither CoffeeScript users, nor || users
(in their defaulting code). They must be doing === undefined test. That
is rare too (not quite as rare as passing null instead of undefined as
intentional default trigger in my experience).
What is your reason for preferring === undefined over == null, since we
have a dilemma and users often use an even looser (falsy, viz ||) test
than == null, but some use == null and others use === undefined, for the
defaulting trigger?
If I can add my own, I use || (because it's short, and if (foo) pattern
desensitivised me), but if there would be an operator for undefined,
I'll switch to use it immediately (I always see it as undefined, knowing
I do sin when using ||).
Btw, |if(foo)| also needs replacement in that case, though if ?? will be
there, |if (foo??true)| (or |if (foo??1)|) would serve the case well.
Well, sorry, not. This is wrong. ?? can't help. |foo ?? 1 : 0| would,
but it's different matter. === undefined is too long, though.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On 14 June 2012 19:01, Brendan Eich bren...@mozilla.com wrote: The users who want null to be distinct from undefined are neither CoffeeScript users, nor || users (in their defaulting code). They must be doing === undefined test. Not quite. I use || whenever I can in my defaulting code, and I can use it a lot (e.g., when the optional item must be an object). I only use the long-winded version if I have to because 0, , false, or null is a valid possible value -- which is surprisingly rare. Hugely looking forward to using ?? uniformly instead, but it's not accurate to say that we who don't want undefined and null equated in this context are therefore not using ||. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Thu, Jun 14, 2012 at 11:01 AM, Brendan Eich bren...@mozilla.com wrote: We have a problem with || indeed. The question is whether the solution should equate null and undefined. CoffeeScript chose the conceal-the-difference path and it has users. The users who want null to be distinct from undefined are neither CoffeeScript users, nor || users (in their defaulting code). They must be doing === undefined test. That is rare too (not quite as rare as passing null instead of undefined as intentional default trigger in my experience). What is your reason for preferring === undefined over == null, since we have a dilemma and users often use an even looser (falsy, viz ||) test than == null, but some use == null and others use === undefined, for the defaulting trigger? I don't claim to be typical in cases like this, but my experience is similar to Herby's - I use || most of the time just because it's short and easy, but switch to x === undefined with a trinary if x might be falsey. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Tab Atkins Jr. wrote: On Thu, Jun 14, 2012 at 11:01 AM, Brendan Eichbren...@mozilla.com wrote: We have a problem with || indeed. The question is whether the solution should equate null and undefined. CoffeeScript chose the conceal-the-difference path and it has users. The users who want null to be distinct from undefined are neither CoffeeScript users, nor || users (in their defaulting code). They must be doing === undefined test. That is rare too (not quite as rare as passing null instead of undefined as intentional default trigger in my experience). What is your reason for preferring === undefined over == null, since we have a dilemma and users often use an even looser (falsy, viz ||) test than == null, but some use == null and others use === undefined, for the defaulting trigger? I don't claim to be typical in cases like this, but my experience is similar to Herby's - I use || most of the time just because it's short and easy, but switch to x === undefined with a trinary if x might be falsey. Yeah, I switch, too. If I see it is needed, and don't forget it. That is why || is uneasy, ?? would remove the fear (in Kent-and-Ward TDD sense). ~TJ Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
T.J. Crowder wrote: On 14 June 2012 19:01, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: The users who want null to be distinct from undefined are neither CoffeeScript users, nor || users (in their defaulting code). They must be doing === undefined test. Not quite. I use || whenever I can in my defaulting code, and I can use it a lot (e.g., when the optional item must be an object). I only use the long-winded version if I have to because 0, , false, or null is a valid possible value -- which is surprisingly rare. Hugely looking forward to using ?? uniformly instead, but it's not accurate to say that we who don't want undefined and null equated in this context are therefore not using ||. Good point, when you are dealing with an object or variable that you know will be either undefined or a well-typed value, you can use ||. But how do you know what is a possible value? Wes testified elsewhere that he had latent bugs. I suspect many APIs whose impls use || do. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola dome...@domenicdenicola.com wrote: In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist. null is intentional, its presence is explicit -- doesn't this imply that something _does_ exist? (...and its value is null) eg. https://gist.github.com/2926029 Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 14, 2012, at 11:01 AM, Brendan Eich wrote:
...
We have a problem with || indeed. The question is whether the solution should
equate null and undefined. CoffeeScript chose the conceal-the-difference path
and it has users. The users who want null to be distinct from undefined are
neither CoffeeScript users, nor || users (in their defaulting code). They
must be doing === undefined test. That is rare too (not quite as rare as
passing null instead of undefined as intentional default trigger in my
experience).
What is your reason for preferring === undefined over == null, since we have
a dilemma and users often use an even looser (falsy, viz ||) test than ==
null, but some use == null and others use === undefined, for the defaulting
trigger?
I guess my concern is that there are significant existing subsystems where null
is distinguished from undefined or where null has a specifically defined
meaning that does not apply to undefined. For example:
[[Prototype]] manipulation (Object.create, Object.getPrototypeOf,
__proto__)
RegExp exec and derived APIs
JSON stringify/parse
the DOM (WebIDL, provides lots of options vis [TreatUndefinedAs]] to
explicitly control the mapping of undefined)
Any of these might yield null values that downstream might want to be
distinguished from an unintentional undefined (result of a bogus property
access) or explicitly empty parameter slot. My sense is that equating undefined
and null for the purpose of supplying default values is going to preclude
default value usage in any context where null has a specific meaning. Equating
null and undefined in the sole form of default seems value assignment seems to
be a bigger commitment to the path of generally trying to conceal the
distinction between null and undefined. If we want to commit to that path,
then we probably should be explicit about it and make sure that we generally
try to avoid new use cases that distinguish them.
For example, for class definitions I have a draft spec. such that (class
extends undefined { }) means the same things as (class {}) which means
something different from than (class extends null { }. If our goal is generally
to conceal the difference between undefined and null, I would probably change
that equivalence. Note that this all would probably also have implications for
reflective APIs that someone might build in support of classes.
One way to have it both ways is to have multiple syntactic forms for default
value initializers. EG:
function f(a = 1, b ??= 2, c ||= 3) { } //assuming ??= is undefined or null
defaulting guard and ||= is falsy
I'm not particularly convinced that the additional complexity is warranted but
it would place the choice into ES programmers hands rather us trying to
anticipate the typical intent and disadvantaging the untypical.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Jun 14, 2012, at 14:03, Rick Waldron waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote: On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist. null is intentional, its presence is explicit -- doesn't this imply that something _does_ exist? (...and its value is null) eg. https://gist.github.com/2926029 Rick Right, I wasn't exactly clear—I meant more the case of e.g. nothing exists in the database, so I gave you back a null or even there wasn't any error, so I called you back with a null as the first param. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Thu, Jun 14, 2012 at 2:39 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
snip
I guess my concern is that there are significant existing subsystems where
null is distinguished from undefined or where null has a specifically
defined meaning that does not apply to undefined. For example:
[[Prototype]] manipulation (Object.create, Object.getPrototypeOf,
__proto__)
RegExp exec and derived APIs
JSON stringify/parse
the DOM (WebIDL, provides lots of options vis [TreatUndefinedAs]] to
explicitly control the mapping of undefined)
More examples... event objects created by DOM APIs use null as the initial
value of any data property whose value won't be known until an actual event
has occurred.
See:
http://www.w3.org/TR/webmessaging/
http://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120614/
snip
One way to have it both ways is to have multiple syntactic forms for
default value initializers. EG:
function f(a = 1, b ??= 2, c ||= 3) { } //assuming ??= is undefined or
null defaulting guard and ||= is falsy
I'm not particularly convinced that the additional complexity is warranted
but it would place the choice into ES programmers hands rather us trying to
anticipate the typical intent and disadvantaging the untypical.
I agree with this entirely.
||= is complementary to || and makes sense - developers will embrace this
as is.
?? and ??= seem like something is unknown and unknown things can
otherwise be described as undefined. Definitively, |null| is intentional
-- which implies something known and therefore cannot qualify as
undefined. I think sticking to undefined will help to fix the abused ==
null patterns in extant code (I'm thinking in the long term of course)
If null testing is needed:
a = a != null ? a : default;
I realize that the strawman currently spells it ?:, consider this message
an opposition to that.
Rick
Allen
___
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: ||= is much needed?
On Thu, Jun 14, 2012 at 4:04 PM, Rick Waldron waldron.r...@gmail.comwrote: I realize that the strawman currently spells it ?:, consider this message an opposition to that. This has been an extension to C for quite some time, and it means specifically to use the condition value if it is truthy (and is itself derived from the behavior of a ? a : b). I think it would be a mistake to change that behavior from what is expected. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Rick Waldron wrote:
One way to have it both ways is to have multiple syntactic forms
for default value initializers. EG:
function f(a = 1, b ??= 2, c ||= 3) { } //assuming ??= is
undefined or null defaulting guard and ||= is falsy
I'm not particularly convinced that the additional complexity is
warranted but it would place the choice into ES programmers hands
rather us trying to anticipate the typical intent and
disadvantaging the untypical.
I agree with this entirely.
Including the part where Allen is not convinced to add all these forms?
I can see adding ?? and ??= (undefined-only, not undefined-or-null).
Is ||= really worth it? It would not assign if the left side is truthy,
but perhaps no one will mind.
Given ||= is there any oxygen left in the room for ??=?
/be
||= is complementary to || and makes sense - developers will embrace
this as is.
?? and ??= seem like something is unknown and unknown things can
otherwise be described as undefined. Definitively, |null| is
intentional -- which implies something known and therefore cannot
qualify as undefined. I think sticking to undefined will help to fix
the abused == null patterns in extant code (I'm thinking in the long
term of course)
If null testing is needed:
a = a != null ? a : default;
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Thu, Jun 14, 2012 at 5:32 PM, T.J. Crowder t...@crowdersoftware.comwrote: Is ||= really worth it? It would not assign if the left side is truthy, but perhaps no one will mind. Nice-to-have. The fact it doesn't assign if the left side is truthy is the only reason for having it, surely? Plus not even evaluating the RHS if the LHS is truthy -- useful if the default is an expensive calculation. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
More fun with undefined
Making a point of making this a separate thread from the current ??
and ??=thread(s), which are thankfully looking close to consensus. So
that's infix
and assignment.
Question: Should we consider unary as well?
I ask because I went searching through my code (and others') to see where
I'd get a lot of use out of ?? and ??=, and I will, but I also found a
**lot** of:
// 1
if (typeof foo === undefined) { // Or foo === undefined
// ...
}
and
// 2
if (typeof foo !== undefined) { // Or foo !== undefined
// ...
}
and
// 3
a = typeof foo !== undefined foo;
...in my code, in jQuery, and in Prototype. jQuery also has a fair bit of
this (which I find slightly odd, but...):
// 4
a = typeof foo !== undefined foo(arg);
Given ?? and ??=, is there a call for some unary form addressing the above?
Oddly, I think it would make the most sense if it were in the positive
(true if the argument _is_ undefined).
Just for illustration, I'll use £ as though it were an operator (because
obviously it won't be that, and worrying about spelling is something we
only need to do if the semantics are justified). The rule is simple:
evaluates true if its argument is undefined, false otherwise:
// 1
if (£foo) {
// foo === undefined
}
and
// 2
if (!£foo) {
// foo !== undefined
}
and
// 3
a = !£foo foo;
// a becomes foo if foo !== undefined
// a becomes false if foo === undefined
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 14 June 2012 23:10, T.J. Crowder t...@crowdersoftware.com wrote: The rule is simple: evaluates true if its argument is undefined, false otherwise: Slip of the fingers there. £, obviously. Not . And again, the symbol is unimportant for now. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
On Thu, Jun 14, 2012 at 7:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This is basically what I am doing except I find Array#indexOf as it is
pointless ... or better, something that should be fixed in the next version
of ECMAScript.
I agree. I argued that it should be fixed as of ES5, but lost the
argument on compatibility grounds. No one had measurements either way,
so in the absence of evidence we properly made the conservative
choice. The other place where this occurs, and IMO is an even worse
problem is switch:
function sw(x) {
switch (x) {
case NaN: return 'match';
default: return 'default';
}
}
sw(NaN);// returns: 'default'
It's too late for ES6. In order to fix these for ES7, someone would
need to gather evidence that the web corpus does not depend on the
current broken behavior.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On Jun 14, 2012, at 3:10 PM, T.J. Crowder wrote:
Making a point of making this a separate thread from the current ?? and ??=
thread(s), which are thankfully looking close to consensus. So that's infix
and assignment.
Question: Should we consider unary as well?
I ask because I went searching through my code (and others') to see where I'd
get a lot of use out of ?? and ??=, and I will, but I also found a **lot** of:
// 1
if (typeof foo === undefined) { // Or foo === undefined
// ...
}
This is a different issue, but I wonder how badly the web would break if we
made undefined a reserved word. Does anybody in JS really declare a different
local binding for undefined? In ES5 we got away with making undefined
read-only. Maybe we should continue pushing and see if we can eliminate the
rebindable undefined hazard.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On Thu, Jun 14, 2012 at 5:35 PM, Thaddee Tyl thaddee@gmail.com wrote:
On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This is a different issue, but I wonder how badly the web would break if
we
made undefined a reserved word. Does anybody in JS really declare a
different local binding for undefined? In ES5 we got away with making
undefined read-only. Maybe we should continue pushing and see if we can
eliminate the rebindable undefined hazard.
JQuery [1] famously has an undefined parameter, like so:
(function( window, undefined ) { … }(window))
Actually, this exists because undefined wasn't reserved. We would certainly
remove the formal param in favor of an reserved undefined. Unfortunately,
we can't take it back in extant code.
Rick
What would happen in this case?
[1] http://code.jquery.com/jquery-1.7.2.js
___
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: ||= is much needed?
On Thu, Jun 14, 2012 at 6:06 PM, Aymeric Vitte vitteayme...@gmail.comwrote:
This discussion I think is going into a useless complexity.
Nobody (except w3c) is using null, or when someone is using it, it is the
same way as undefined, and it is not explicit (ie a||b or a==b, not
a===null), I remind some old code where we could see the use of null but
can not find a single example of recent code, then the new operator(s)
should treat it the same way I believe, the problem is 0 here
There doesn't need to be an explicit check for undefined - anytime null is
used as an intentional place holder and its value would be _otherwise_
undefined counts as well.
And for your information, I am not w3c and I use null frequently (the same
way w3c uses it).
Rick
Le 14/06/2012 23:16, Rick Waldron a écrit :
On Thu, Jun 14, 2012 at 3:45 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
One way to have it both ways is to have multiple syntactic forms
for default value initializers. EG:
function f(a = 1, b ??= 2, c ||= 3) { } //assuming ??= is
undefined or null defaulting guard and ||= is falsy
I'm not particularly convinced that the additional complexity is
warranted but it would place the choice into ES programmers hands
rather us trying to anticipate the typical intent and
disadvantaging the untypical.
I agree with this entirely.
Including the part where Allen is not convinced to add all these forms?
Yes.
...But it felt useful to note that ||= would compliment || and
immediately understood by devs
I can see adding ?? and ??= (undefined-only, not undefined-or-null).
Yes, absolutely.
Is ||= really worth it? It would not assign if the left side is truthy,
but perhaps no one will mind.
That makes complete sense to me, but again - it might not be worth
adding, because a = b || c isn't that painful.
Given ||= is there any oxygen left in the room for ??=?
Right now, I believe the whole set compliment the current language and
its operators nicely - but if it came down to one or the other, I would
prefer seeing the new addition of ?? and ??=
Rick
/be
||= is complementary to || and makes sense - developers will embrace
this as is.
?? and ??= seem like something is unknown and unknown things can
otherwise be described as undefined. Definitively, |null| is intentional
-- which implies something known and therefore cannot qualify as
undefined. I think sticking to undefined will help to fix the abused ==
null patterns in extant code (I'm thinking in the long term of course)
If null testing is needed:
a = a != null ? a : default;
___
es-discuss mailing
listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Thu, Jun 14, 2012 at 4:06 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Nobody (except w3c) is using null, or when someone is using it, it is the same way as undefined, and it is not explicit (ie a||b or a==b, not a===null), I remind some old code where we could see the use of null but can not find a single example of recent code, then the new operator(s) should treat it the same way I believe, the problem is 0 here Your experience isn't necessarily universal. I've used null before to mean something different than undefined. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On Jun 14, 2012, at 3:49 PM, Rick Waldron wrote:
On Thu, Jun 14, 2012 at 5:35 PM, Thaddee Tyl thaddee@gmail.com wrote:
On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This is a different issue, but I wonder how badly the web would break if we
made undefined a reserved word. Does anybody in JS really declare a
different local binding for undefined? In ES5 we got away with making
undefined read-only. Maybe we should continue pushing and see if we can
eliminate the rebindable undefined hazard.
JQuery [1] famously has an undefined parameter, like so:
(function( window, undefined ) { … }(window))
Actually, this exists because undefined wasn't reserved. We would certainly
remove the formal param in favor of an reserved undefined. Unfortunately, we
can't take it back in extant code.
A wonder if this wart is hairy enough, that we wouldn't be justified in some
explicit backwards compatibility hackery in the spec. to remove it.
For example, we could allow it to appear in parameter lists and provide a
dynamic check to ensure that nothing (other than a real undefined) is passed.
Similarly we could explicitly allow:
var undefined;
Certainly there is no particular reasons we need to allow:
let undefined;
const undefined=true;
class undefined extends foo { }
or any other new binding forms redefining undefined.
Allen
Rick
What would happen in this case?
[1] http://code.jquery.com/jquery-1.7.2.js
___
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: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
The opposite seems to be true: https://gist.github.com/gists/search?q=%22case+NaN%22x=0y=0 https://github.com/search?q=%22case+NaN%22type=Everythingrepo=langOverride=start_value=1 On Thu, Jun 14, 2012 at 5:25 PM, Mark S. Miller erig...@google.com wrote: It's too late for ES6. In order to fix these for ES7, someone would need to gather evidence that the web corpus does not depend on the current broken behavior. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[strawman:data_parallelism]] |this| and fat arrows
Hi Rick,
Even without =, I think this is an improvement to the API overall, as
it makes it more similar to the corresponding array methods. However,
I do not see the problem with making it much more similar. I agree
regarding reduce and reduceRight, but fortunately, these already
violate the general pattern for the other higher order array methods
-- in that they call their callbackfn with this always bound to
undefined. In retrospect, I wish we had called the existing function
reduceLeft so yours could be called simply reduce and have the
name difference suggest the lack of order.
Regarding the others, the general pattern from the ho array methods is
array.foo(callbackfn, possible-other-args, optional-this-arg)
calls back
callbackfn(value, index, array, this-arg-or-undefined)
I wish that the optional-this-arg had been omitted from ES5, but for
the sake of compat with the Prototype library and other
implementations of these methods, I lost that argument. In retrospect
I agree with that decision, even though I still believe that the
this-arg has net negative value. By the same reasoning, I think you
should follow this pattern as well except when there's a good argument
not to. For reduce you make a good argument.
Further comments inline below.
On Fri, Jun 15, 2012 at 4:27 AM, Hudson, Rick rick.hud...@intel.com wrote:
Proposed change to [[strawman:data_parallelism]]
The ParallelArray methods map, combine, reduce, scan, scatter, and filter,
each take a kernel function as an argument. Within this kernel function
|this| is currently bound to the ParallelArray. This was natural and
non-controversial
I disagree that it was non-controversial -- I argued against it on
compat grounds at the time. But I agree with your point that = makes
that old design even less viable.
as long as we used the function(){..} form which did not
restrict how |this| was bound and explaining the semantics in terms of call
or apply was perfectly reasonable. = is likely to change that. =, as
proposed, enforces a lexical |this| and is semantically different than the
function () {..} form. Going forward we expect folks to use the = form more
than the function form. For the most part we will be leaving the kernel
signatures as they are except that we will no longer bind |this| to the
ParalleArray is inside a kernel function. Instead |this| will be bound in
accordance to existing JavaScript specifications and
[[strawman:data_parallelism]] will no longer refer to |this|. For the
combine method which currently gets only an index as an argument we will now
also pass the ParallelArray in. If the programmer wants the ParallelArray in
methods like reduce or map then it will have to be passed in as a free
variable.
We considered and decided not to mimic Array's function (element, index,
array) { ... } form. We felt that it causes intellectual confusion about
parallel programming since passing in index and array force the programmer
to think about things like order and location when using methods like map.
This seems to be your key point, and I don't understand it at all.
Since you single out map, could you please explain how this causes any
confusion when using map? Thanks.
It is even more intellectually confusing when using reduce since in a
parallel world both of the values passed in may be the results of previous
kernel invocations and as such not have an index in any reasonable sense.
For combine and filter we pass the ParallelArray in as the second argument.
For the other methods one can pass the ParallelArray in using a free
variable.
- Rick
___
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: ||= is much needed?
Just clarifying -- we all agree that any such thing is too late for ES6, right? On this assumption, I'm postponing engaging in this thread until I have time. On Fri, Jun 15, 2012 at 4:43 AM, Brendan Eich bren...@mozilla.com wrote: Yes, I'm about to bail back to ??. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Before... I put Rick's answer below too, in strict/correct code it can be used but what examples (except yours) ? Maybe I missed it, never saw the use of null since a long time, but I can be wrong Do you think it does worth the complexity for the operators we are talking about ? w3c is forced to define something as null, would look strange and not serious to define it as undefined in specs, but in reality this is let to the appreciation of developers (who usually don't care), and for comparisons/default, null will, I think, never be used, then it should probably behave the same as undefined Le 15/06/2012 01:12, Tab Atkins Jr. a écrit : On Thu, Jun 14, 2012 at 4:06 PM, Aymeric Vittevitteayme...@gmail.com wrote: Nobody (except w3c) is using null, or when someone is using it, it is the same way as undefined, and it is not explicit (ie a||b or a==b, not a===null), I remind some old code where we could see the use of null but can not find a single example of recent code, then the new operator(s) should treat it the same way I believe, the problem is 0 here Your experience isn't necessarily universal. I've used null before to mean something different than undefined. ~TJ There doesn't need to be an explicit check for undefined - anytime null is used as an intentional place holder and its value would be _otherwise_ undefined counts as well. And for your information, I am not w3c and I use null frequently (the same way w3c uses it). -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Just to be clear I am talking about the use of null in the scope of the current discussion (ie operators/default) only Le 15/06/2012 01:37, Aymeric Vitte a écrit : Before... I put Rick's answer below too, in strict/correct code it can be used but what examples (except yours) ? Maybe I missed it, never saw the use of null since a long time, but I can be wrong The difference is known, do you think it does worth the complexity for the operators we are talking about ? w3c is forced to define something as null, would look strange and not serious to define it as undefined in specs, but in reality this is let to the appreciation of developers (who usually don't care), and for comparisons/default, null will, I think, never be used, then it should probably behave the same as undefined Le 15/06/2012 01:12, Tab Atkins Jr. a écrit : On Thu, Jun 14, 2012 at 4:06 PM, Aymeric Vittevitteayme...@gmail.com wrote: Nobody (except w3c) is using null, or when someone is using it, it is the same way as undefined, and it is not explicit (ie a||b or a==b, not a===null), I remind some old code where we could see the use of null but can not find a single example of recent code, then the new operator(s) should treat it the same way I believe, the problem is 0 here Your experience isn't necessarily universal. I've used null before to mean something different than undefined. ~TJ There doesn't need to be an explicit check for undefined - anytime null is used as an intentional place holder and its value would be _otherwise_ undefined counts as well. And for your information, I am not w3c and I use null frequently (the same way w3c uses it). -- jCore Email :avi...@jcore.fr Web :www.jcore.fr Webble :www.webble.it Extract Widget Mobile :www.extractwidget.com BlimpMe! :www.blimpme.com -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)
On Jun 14, 2012, at 4:30 PM, Michael Haufe wrote:
The opposite seems to be true:
https://gist.github.com/gists/search?q=%22case+NaN%22x=0y=0
this only has
case NaN:
not
case NaN:
https://github.com/search?q=%22case+NaN%22type=Everythingrepo=langOverride=start_value=1
And the above isn't only looking at JS code. If you limit the search to
javascript code the only result that actually matches case NaN: is what
appears to be a SpiderMonkey test case that is replicated several places
// No test case, just make sure this doesn't assert.
function testNegZero2() {
var z = 0;
for (let j = 0; j 5; ++j) { ({p: (-z)}); }
}
testNegZero2();
function testConstSwitch() {
var x;
for (var j=0;j5;++j) { switch(1.1) { case NaN: case 2: } x = 2; }
return x;
}
assertEq(testConstSwitch(), 2);
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
I don't think it matters yet, this is fair game for es-discuss as a harmony strawman. But it does connect to parameter default values, where we have open issues that come up here too. Worth skimming IMHO. /be On Jun 14, 2012, at 6:35 PM, Mark S. Miller erig...@google.com wrote: Just clarifying -- we all agree that any such thing is too late for ES6, right? On this assumption, I'm postponing engaging in this thread until I have time. On Fri, Jun 15, 2012 at 4:43 AM, Brendan Eich bren...@mozilla.com wrote: Yes, I'm about to bail back to ??. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
