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
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
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
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.
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
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
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
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
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
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
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
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 =
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],
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
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()
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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 !==
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
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
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
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,
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
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
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
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
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
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.
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
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
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
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
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
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?
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
62 matches
Mail list logo
