Re: Function.length and Default Parameters
On Thursday, October 11, 2012 at 11:25 PM, Kevin Smith wrote:
And specifically not stopping counting at the first parameter with a
default value, right?
Yep. Would it also work for this use case to stop counting at the first
parameter with no default value, after which there are only defaults?
function f(a, b = 2, c, d = 4, ...rest) {}
f.length === 3;
Probably? Not sure...
Neither am I...
This looks like the sort of thing that will get labeled uselessly unreliable,
then again I was in favor of making length equal the number of formal
parameters—rest included.
Rick
Kevin
___
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: Function.length and Default Parameters
This looks like the sort of thing that will get labeled uselessly unreliable, then again I was in favor of making length equal the number of formal parameters—rest included. Right - the simpler the rule, the better for this kind of thing. I wouldn't include rest, though, because it's cardinality is really infinity, and therefore not particularly useful in this context. But the simplest rule would require a change to the reported length of some built-ins, as Allen has said. Tradeoffs... Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
On Friday, October 12, 2012 at 9:18 AM, Kevin Smith wrote: This looks like the sort of thing that will get labeled uselessly unreliable, then again I was in favor of making length equal the number of formal parameters—rest included. Right - the simpler the rule, the better for this kind of thing. I wouldn't include rest, though, because it's cardinality is really infinity, and therefore not particularly useful in this context. +1 Sorry, should've clarified: that was my initial inclination, some time ago. Yes I agree with everything but the rest. Rick But the simplest rule would require a change to the reported length of some built-ins, as Allen has said. Tradeoffs... Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Mootools and String.prototype.contains
Hi, I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant. David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=781796 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=789036 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
On Fri, Oct 12, 2012 at 9:23 AM, Rick Waldron waldron.r...@gmail.com wrote: Right - the simpler the rule, the better for this kind of thing. Anything but optional and rest (as speced) is the simplest rule I can think of, except everything including rest, but no one wants that. The problem is that length is not useful for reflection anyway. The right way forward is to provide a better reflection API that exposes all the relevant information about the parameters. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mootools and String.prototype.contains
Hello, I've found the issue in mootools-core [1]. [1] https://github.com/mootools/mootools-core/issues/2402 Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mootools and String.prototype.contains
It's unclear what we should do here. Their test-and-install mechanism was overly optimistic and therefore future hostile. It looks as though outreach is happening and they're fixing their library and aligning with ES6 in future releases. My suggestion is to wait-and-see what browser vendor advocacy can accomplish without either changing the name of contains() in the drafts or removing it. On Fri, Oct 12, 2012 at 3:04 PM, Yusuke Suzuki utatane@gmail.comwrote: Hello, I've found the issue in mootools-core [1]. [1] https://github.com/mootools/mootools-core/issues/2402 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
Re: Function.length and Default Parameters
Anything but optional and rest (as speced) is the simplest rule I can
think of, except everything including rest, but no one wants that.
But the current spec does not say that. It says stop counting at the first
default, which doesn't really tell anyone anything useful about the
function's signature.
function f(a = 1, b, c, d, e, f) {}
f.length === 0; // Huh?
Unless I'm misreading...?
Simple may be in the eye of the beholder, but I contend that the above is
surprising.
The problem is that length is not useful for reflection anyway. The
right way forward is to provide a better reflection API that exposes
all the relevant information about the parameters.
A better reflection API sounds good, but your statement that length is not
useful is demonstrably false. API judgements aside, we know that it is
currently used with non-WTF results.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mootools and String.prototype.contains
On 12/10/12 14:50, David Bruant wrote: I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant. Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mootools and String.prototype.contains
Good context. I didn't know that they had b0rked bind() as well ;-) I feel like there's as PSA we should write over on webplatform.org for library authors about how to not be future hostile. On Fri, Oct 12, 2012 at 3:26 PM, Geoffrey Sneddon gsned...@opera.comwrote: On 12/10/12 14:50, David Bruant wrote: I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant. Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com __**_ 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
Map/Set.prototype.size
Hi, Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. Unlike Java, JavaScript is lucky enough to have getter/setters, we should use them, even in the spec. The boat for myArray.length has sunk a while ago, but new constructs can get this right. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
+1 On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com wrote: Hi, Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. Unlike Java, JavaScript is lucky enough to have getter/setters, we should use them, even in the spec. The boat for myArray.length has sunk a while ago, but new constructs can get this right. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
+1 On Fri, Oct 12, 2012 at 4:19 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: +1 On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com wrote: Hi, Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. Unlike Java, JavaScript is lucky enough to have getter/setters, we should use them, even in the spec. The boat for myArray.length has sunk a while ago, but new constructs can get this right. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ 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: should we rename the Program grammar production?
list-noob here - I hope this gets threaded ok. One of the pieces of awkward ES specification terminology has been the use of the word Program as the name for a global top-level StatementList. This, I think is what (the noun) program should be reserved for. A ES Program is commonly only a single fragment of what most of us commonly think of as a program. And these sub-components are lesser nouns, script -s This terminology mismatch is going to get ever worse as we integrate modules. All of which are scripts to become a part of the global top-level StatementList = Program. Said another way, we don't directly write programs, we compose scripts which are marshalled/assembled into the Program by the runtime/compiler, which is, if I've understood Allen (heck, even myself!) correctly, the opposite of what Allen is suggesting : I proposed that we replace Program in this context with Script. This is much less confusing and matches the most common manifestation of an ES Program as an HTML script block. And of course, script is only *one* mechanism by which scripts are placed in the Program/global top-level StatementList (modules, node et al). $0.02 Russ / @codacoder ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
Would .size be {[[Writable]]:false}?
let s = new Set([1,2,3,4]);
s.size; // 4
s.size = 1; // fail silently (loudly in strict mode)?
I swear there was some discussion either at an in-person on this list, but
I'm having no luck tracking it down...
Rick
On Fri, Oct 12, 2012 at 11:28 AM, Alex Russell slightly...@google.comwrote:
+1
On Fri, Oct 12, 2012 at 4:19 PM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
+1
On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com
wrote:
Hi,
Firefox has implement a Map/Set.prototype.size *method* to query the
number
of mapping/elements.
It's not in the strawman. It appears in the latest draft, though weirdly
enough Map.prototype.size is a function with an unused argument.
What about making it an getter instead of a function? I guess we also
don't
need the extra parens to request for Map#keys, Map#values, Map#items.
Unlike Java, JavaScript is lucky enough to have getter/setters, we
should
use them, even in the spec. The boat for myArray.length has sunk a while
ago, but new constructs can get this right.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
On Fri, Oct 12, 2012 at 11:41 AM, Rick Waldron waldron.r...@gmail.com wrote:
Would .size be {[[Writable]]:false}?
It would be a getter on the prototype (and no setter)
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mootools and String.prototype.contains
On Fri, Oct 12, 2012 at 10:09 AM, Alex Russell slightly...@google.comwrote: It's unclear what we should do here. Their test-and-install mechanism was overly optimistic and therefore future hostile. It looks as though outreach is happening and they're fixing their library and aligning with ES6 in future releases. My suggestion is to wait-and-see what browser vendor advocacy can accomplish without either changing the name of contains() in the drafts or removing it. I agree. ES6 standardization isn't due until Dec 2013, which gives browser vendors and lib authors over a year to spread the word, fix implementations, update code, etc. Rick On Fri, Oct 12, 2012 at 3:04 PM, Yusuke Suzuki utatane@gmail.comwrote: Hello, I've found the issue in mootools-core [1]. [1] https://github.com/mootools/mootools-core/issues/2402 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
On Oct 11, 2012, at 8:11 PM, Rick Waldron wrote: On Thursday, October 11, 2012 at 7:36 PM, Kevin Smith wrote: express for node already does this, for error handlers: http://expressjs.com/guide.html#error-handling express is very popular; #4 on Most Depended Upon packages; #1 on Most Starred at npm: This is helpful. So, judgement aside, we can say there is a certain level of usage of Function.length out there for overloading based on a function's signature. It seems to me that reporting Function.length as the number of formal parameters, minus rest, will be more appropriate for this use case. Having trouble finding the resolution, but I'm fairly certain this was discussed and your suggestion here matches consensus Previous threads where this topic was discussed: https://mail.mozilla.org/pipermail/es-discuss/2012-June/023277.html https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html https://mail.mozilla.org/pipermail/es-discuss/2011-September/016417.html There was no consensus to change the current ES6 draft specification for function length. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
On Fri, Oct 12, 2012 at 11:43 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
On Fri, Oct 12, 2012 at 11:41 AM, Rick Waldron waldron.r...@gmail.com
wrote:
Would .size be {[[Writable]]:false}?
It would be a getter on the prototype (and no setter)
+1, That works for me.
Rick
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
On Fri, Oct 12, 2012 at 11:53 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Oct 11, 2012, at 8:11 PM, Rick Waldron wrote: On Thursday, October 11, 2012 at 7:36 PM, Kevin Smith wrote: express for node already does this, for error handlers: http://expressjs.com/guide.html#error-handling express is very popular; #4 on Most Depended Upon packages; #1 on Most Starred at npm: This is helpful. So, judgement aside, we can say there is a certain level of usage of Function.length out there for overloading based on a function's signature. It seems to me that reporting Function.length as the number of formal parameters, minus rest, will be more appropriate for this use case. Having trouble finding the resolution, but I'm fairly certain this was discussed and your suggestion here matches consensus Previous threads where this topic was discussed: https://mail.mozilla.org/pipermail/es-discuss/2012-June/023277.html https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html https://mail.mozilla.org/pipermail/es-discuss/2011-September/016417.html There was no consensus to change the current ES6 draft specification for function length. Sorry, I didn't mean consensus to change anything—my fairly certain above was just wrong as I had forgotten this: or the first FormalParameter with an Initialiser.. Apologies for the confusion. Rick Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
On Oct 11, 2012, at 4:36 PM, Kevin Smith wrote:
express for node already does this, for error handlers:
http://expressjs.com/guide.html#error-handling
express is very popular; #4 on Most Depended Upon packages; #1 on Most
Starred at npm:
This is helpful. So, judgement aside, we can say there is a certain level of
usage of Function.length out there for overloading based on a function's
signature. It seems to me that reporting Function.length as the number of
formal parameters, minus rest, will be more appropriate for this use case.
Have you found the actual usage of length in node libraries to enforce this
sort of signature testing? I was poking around and haven't found it. Note
that the http://expressjs.com/guide.html#error-handling only says must be
defined with an arity of 4, that is the signature (err, req, res, next). It
doesn't say that length is use to enforce this. It might be doing a toString
on the function or something else.
Regardless, the specification function length in the current ES6 draft would
not break such length-based detection. If you write function (err,
req,res,next){}.length you will get 4, just like with ES5.1 So this isn't a
breaking change. Any new use of new parameter forms would be a violation of
the must in the above quote from the express documentation.
So, so far, I have really seen anything new in this recent thread that would
cause us to change the decision that has already been made.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
There was additional discussion of length in the context of the internationalization API, and a decision at the July TC 39 meeting to Apply ES6 rules to all functions in Internationalization API. [1] By ES6 rules we meant what Allen had proposed [2] and what's in section 13.1 of the ES6 draft: NOTE The ExpectedArgumentCount of a FormalParameterList is the number of FormalParameters to the left of either the rest parameter or the first FormalParameter with an Initialiser. A FormalParameter without an initializer are allowed after the first parameter with an initializer but such parameters are considered to be optional with undefined as their default value. This means, optional arguments don't count. [1] https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html [2] https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html Norbert On Oct 12, 2012, at 8:53 , Allen Wirfs-Brock wrote: On Oct 11, 2012, at 8:11 PM, Rick Waldron wrote: On Thursday, October 11, 2012 at 7:36 PM, Kevin Smith wrote: express for node already does this, for error handlers: http://expressjs.com/guide.html#error-handling express is very popular; #4 on Most Depended Upon packages; #1 on Most Starred at npm: This is helpful. So, judgement aside, we can say there is a certain level of usage of Function.length out there for overloading based on a function's signature. It seems to me that reporting Function.length as the number of formal parameters, minus rest, will be more appropriate for this use case. Having trouble finding the resolution, but I'm fairly certain this was discussed and your suggestion here matches consensus Previous threads where this topic was discussed: https://mail.mozilla.org/pipermail/es-discuss/2012-June/023277.html https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html https://mail.mozilla.org/pipermail/es-discuss/2011-September/016417.html There was no consensus to change the current ES6 draft specification for function length. 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
Cross-frame symbols
I’m not sure that I don’t understand all the issues involved, but making symbols global just for cross-frame communication seems like an extreme measure. If that is possible, it would be great if we could fix cross-frame communication completely – also for instanceof, not just for symbols. Does it make sense to view this as a serialization problem? One faces the same problem as in sending an object over a wire: If you create new Foo() at one end, you want that object to be instanceof Foo at the other end. Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
Given that you need to import symbols, I prefer explicit declarations (which will also be used for exporting). On Oct 11, 2012, at 23:41 , Kevin Smith khs4...@gmail.com wrote: Hi all, ES6 is shaping up quite nicely. The last big area which I feel is still quite foggy is syntactic support for symbolic property names, which Allen has addressed with his at-names proposal. Perhaps syntax won't make it into ES6 regardless of the work we do, but I think the symbol story isn't finished until we've got something. With that in mind, I've created a sketch of an alternative at-name syntax story. I've tried to include enough detail to show that it might work, but not so much that I never finish the sketch : ) The basic idea is that modules implicitly define symbol namespaces. Symbols can be imported from other modules, or from a world symbol map which contains interned symbols for the entire execution environment. Read on: https://gist.github.com/3868131 The actual design sketch follows some initial examples. Thanks! Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
Have you found the actual usage of length in node libraries to enforce
this sort of signature testing? I was poking around and haven't found it.
Note that the http://expressjs.com/guide.html#error-handling only says
must be defined with an arity of 4, that is the signature (err, req,
res, next). It doesn't say that length is use to enforce this. It
might be doing a toString on the function or something else.
https://github.com/visionmedia/express/blob/master/lib/router/index.js#L159
Regardless, the specification function length in the current ES6 draft
would not break such length-based detection. If you write function (err,
req,res,next){}.length you will get 4, just like with ES5.1 So this isn't
a breaking change. Any new use of new parameter forms would be a violation
of the must in the above quote from the express documentation.
Sure, it's not breaking, but that doesn't mean that it makes sense for the
use case we're talking about.
Again:
function f(a = 1, b, c) {}
f.length === 0; // Huh?
On what basis does reporting 0 make sense? How does that communicate
anything at all about the function?
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
Given that you need to import symbols, I prefer explicit declarations (which will also be used for exporting). Thanks for your feedback! The problem with explicit declarations is that it's going to be burdensome, for no apparent gain. Consider: I have a real-world class with 37 internal methods which are prefixed with an underscore. I'm not kidding. Explicit declaration means that I have to maintain a list of 37 at-name declarations, separate from the class definition itself, which contributes *no real information* that isn't available elsewhere in the module code. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Function.length and Default Parameters
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Kevin Smith [khs4...@gmail.com]
Sent: Friday, October 12, 2012 12:30
Again:
function f(a = 1, b, c) {}
f.length === 0; // Huh?
You seem to be under the mistaken impression that ES6 allows non-defaulted
arguments after default ones. This is not the case. See
https://mail.mozilla.org/pipermail/es-discuss/2012-October/025704.html
for a (very) recent discussion of this.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
Have you found the actual usage of length in node libraries to enforce this sort of signature testing? I was poking around and haven't found it. Side question: has tc39 tried to contact any of the research groups that specialize in large-scale repository mining? Usage questions here are often not answerable with a simple grep, even though there are lots of JS repositories (github, npm, ..). One needs repo access, storage and search resources, and specialized analysis (at least syntax). Perhaps some research groups would welcome a challenge with real-world impact, either as specific projects or as a wiki page with challenges from which research students in those groups could pick topics to work on. Usually, those groups mine repo histories, for trends related to software engineering topics, but their setups might work, or might be adaptable to, tc39's JS-in-the-real-world usage questions. Once such a setup is in place, tc39 members might use it directly to inform language design decisions. Just a thought, Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
You seem to be under the mistaken impression that ES6 allows non-defaulted arguments after default ones. This is not the case. See https://mail.mozilla.org/pipermail/es-discuss/2012-October/025704.html for a (very) recent discussion of this. I don't think that is true. See Allen's response here: https://mail.mozilla.org/pipermail/es-discuss/2012-October/025709.html Also, I see no evidence in the latest draft that defaults after a non-default is a static error. Please correct me if I'm wrong, of course! Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
Also, I see no evidence in the latest draft that defaults after a non-default is a static error. Please correct me if I'm wrong, of course! Sorry, meant non-defaults after a default in the above. Need...more...coffeee. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
On Oct 12, 2012, at 13:03, Kevin Smith khs4...@gmail.commailto:khs4...@gmail.com wrote: You seem to be under the mistaken impression that ES6 allows non-defaulted arguments after default ones. This is not the case. See https://mail.mozilla.org/pipermail/es-discuss/2012-October/025704.html for a (very) recent discussion of this. I don't think that is true. See Allen's response here: https://mail.mozilla.org/pipermail/es-discuss/2012-October/025709.html Oh, wow, thanks for correction. Sorry for the noise everyone X_x. I got the opposite impression from other responses in the thread. Will be sure to update the @esdiscuss Twitter account. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Cross-frame symbols
It's unclear how we could possibly do this for anything but built-ins, and even there it's iffy. What if someone extends you builtin's prototype in one frame but not the other? Anyhow, this all bottoms out at object identity. Functions are objects, and declaring identically named objects in different scripting contexts doesn't make the same object. To get there, you need some iron-clad notion of sameness. Inventing it is fraught. My recommendation is to use frames a chunky barriers through which you do IPC, not fine-grained object boundaries over which you call local methods. On Fri, Oct 12, 2012 at 5:21 PM, Axel Rauschmayer a...@rauschma.de wrote: I’m not sure that I don’t understand all the issues involved, but making symbols global just for cross-frame communication seems like an extreme measure. If that is possible, it would be great if we could fix cross-frame communication completely – also for instanceof, not just for symbols. Does it make sense to view this as a serialization problem? One faces the same problem as in sending an object over a wire: If you create new Foo() at one end, you want that object to be instanceof Foo at the other end. Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ 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: Cross-frame symbols
Alex Russell wrote: It's unclear how we could possibly do this for anything but built-ins, and even there it's iffy. What if someone extends you builtin's prototype in one frame but not the other? Anyhow, this all bottoms out at object identity. Functions are objects, and declaring identically named objects in different scripting contexts doesn't make the same object. To get there, you need some iron-clad notion of sameness. Inventing it is fraught. My recommendation is to use frames a chunky barriers through which you do IPC, not fine-grained object boundaries over which you call local methods. +1 If you *do* make a small world network of objects that span frame boundaries, then you're generally keeping it all in the family and can cope via copying, adding instanceOf or typeOf methods, etc. /be On Fri, Oct 12, 2012 at 5:21 PM, Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de wrote: I’m not sure that I don’t understand all the issues involved, but making symbols global just for cross-frame communication seems like an extreme measure. If that is possible, it would be great if we could fix cross-frame communication completely – also for instanceof, not just for symbols. Does it make sense to view this as a serialization problem? One faces the same problem as in sending an object over a wire: If you create new Foo() at one end, you want that object to be instanceof Foo at the other end. Axel -- Dr. Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de home: rauschma.de http://rauschma.de twitter: twitter.com/rauschma http://twitter.com/rauschma blog: 2ality.com http://2ality.com ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
Rick Waldron wrote:
On Fri, Oct 12, 2012 at 11:43 AM, Erik Arvidsson
erik.arvids...@gmail.com mailto:erik.arvids...@gmail.com wrote:
On Fri, Oct 12, 2012 at 11:41 AM, Rick Waldron
waldron.r...@gmail.com mailto:waldron.r...@gmail.com wrote:
Would .size be {[[Writable]]:false}?
It would be a getter on the prototype (and no setter)
+1, That works for me.
+42.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
+1
Dave
On Oct 12, 2012, at 8:43 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
On Fri, Oct 12, 2012 at 11:41 AM, Rick Waldron waldron.r...@gmail.com wrote:
Would .size be {[[Writable]]:false}?
It would be a getter on the prototype (and no setter)
--
erik
___
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: Function.length and Default Parameters
Yes, so given the case Kevin raises of default-ful followed by default-less I agree with Kevin: length should reflect all but rest (if present). Allen, what built-ins would this break, do you know from checking what built-ins break under the current draft's rule? /be Domenic Denicola wrote: On Oct 12, 2012, at 13:03, Kevin Smith khs4...@gmail.com mailto:khs4...@gmail.com wrote: You seem to be under the mistaken impression that ES6 allows non-defaulted arguments after default ones. This is not the case. See https://mail.mozilla.org/pipermail/es-discuss/2012-October/025704.html for a (very) recent discussion of this. I don't think that is true. See Allen's response here: https://mail.mozilla.org/pipermail/es-discuss/2012-October/025709.html Oh, wow, thanks for correction. Sorry for the noise everyone X_x. I got the opposite impression from other responses in the thread. Will be sure to update the @esdiscuss Twitter account. ___ 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: [[Call]] vs. [[Construct]] using symbols
Thanks, Tom. At this point, without a TC39 exception, even with unique symbols, I think this is a strawman (so ES7 at earliest). Anyone willing to write it up? /be Tom Van Cutsem wrote: I think we've been over this before. See the April thread callable objects? Brendan at that point also proposed to use private names (we didn't then have the distinction between private and unique symbols): https://mail.mozilla.org/pipermail/es-discuss/2012-April/022368.html I don't see any problem with this since the call and construct traps don't have any invariant checks associated with them. And I agree it would be weird if proxies were the only available tool to discern [[Call]] from [[Construct]]. Brendan gave more good reasons here: https://mail.mozilla.org/pipermail/es-discuss/2012-April/022394.html. I think the important points w.r.t. invariants are: - you can't override the built-in [[Call]] and [[Construct]] behavior of an ECMAScript function object. - the result of the typeof operator shouldn't depend on the presence/absence of the @call/@construct unique symbols. Cheers, Tom 2012/10/6 Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org Before we add more unstratified traps, I'd like Tom and Mark to comment. They've thought a lot about invariants to preserve even with proxies in the picture, and also for non-proxies. And they have a use-case to test against: SES. Herby Vojčík wrote: But this has some quirks to solve, like typeof must be function for every object having @call, but what about object having only @construct? If we do this, then let's hope testing (@construct in obj) isn't too bad. I suspect it won't be all that common. /be ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com wrote: Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. For keys, values and items I think they are cleaner as methods since they return a new iterator every time. If they were properties, I would expect the following to always be true: map.items === map.items -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
On Fri, Oct 12, 2012 at 12:14 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com wrote: Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. For keys, values and items I think they are cleaner as methods since they return a new iterator every time. If they were properties, I would expect the following to always be true: map.items === map.items Agreed, I expect things that look like properties to be stable. Factories should be methods. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Call]] vs. [[Construct]] using symbols
Brendan Eich wrote: Thanks, Tom. At this point, without a TC39 exception, even with unique symbols, I think this is a strawman (so ES7 at earliest). Anyone willing to write it up? As a generic callable objects proposal, yes. But I am still saying there is a max-min proposal, which only puts this semantics into max-min classes. Where it, imho, has its value, and is easy to implement. This could be part of ES6, wouldn't it? And it could be also the first step to full-blown callable objects, should they appear later. Herby /be Tom Van Cutsem wrote: I think we've been over this before. See the April thread callable objects? Brendan at that point also proposed to use private names (we didn't then have the distinction between private and unique symbols): https://mail.mozilla.org/pipermail/es-discuss/2012-April/022368.html I don't see any problem with this since the call and construct traps don't have any invariant checks associated with them. And I agree it would be weird if proxies were the only available tool to discern [[Call]] from [[Construct]]. Brendan gave more good reasons here: https://mail.mozilla.org/pipermail/es-discuss/2012-April/022394.html. I think the important points w.r.t. invariants are: - you can't override the built-in [[Call]] and [[Construct]] behavior of an ECMAScript function object. - the result of the typeof operator shouldn't depend on the presence/absence of the @call/@construct unique symbols. Cheers, Tom 2012/10/6 Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org Before we add more unstratified traps, I'd like Tom and Mark to comment. They've thought a lot about invariants to preserve even with proxies in the picture, and also for non-proxies. And they have a use-case to test against: SES. Herby Vojčík wrote: But this has some quirks to solve, like typeof must be function for every object having @call, but what about object having only @construct? If we do this, then let's hope testing (@construct in obj) isn't too bad. I suspect it won't be all that common. /be ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map/Set.prototype.size
Erik Arvidsson wrote: On Fri, Oct 12, 2012 at 11:16 AM, David Bruantbruan...@gmail.com wrote: Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. For keys, values and items I think they are cleaner as methods since +1 they return a new iterator every time. If they were properties, I would expect the following to always be true: map.items === map.items Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
Also, I should mention a couple of things:
1. This design essentially paves the cowpath trod with underscore-prefixed
property names, adding the desired property of conflict elimination.
2. If System is a built-in *module instance*, and the @iterator symbol
is defined internally within that module as:
sym @iterator = org.ecma-whatever.es.6.iterator; // Or perhaps more
likely a uuid...
Then we have exactly the desired syntax that we're looking for:
import @iterator from System; // no funky @belch URLs!!
class C {
@iterator() { ... }
}
And it works cross-frame, cross-loader-context and all.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
String.prototype.localeCompare Number.prototype.toLocaleString Date.prototype.toLocaleString Date.prototype.toLocaleDateString Date.prototype.toLocaleTimeString Intl.Collator Intl.Collator.supportedLocalesOf Intl.NumberFormat Intl.NumberFormat.supportedLocalesOf Intl.DateTimeFormat Intl.DateTimeFormat.supportedLocalesOf the function returned by Intl.DateTimeFormat.prototype.format ...are all specified in the ECMAScript Internationalization API Specification as taking optional arguments, but not counting them towards the value of their length properties. Norbert On Oct 12, 2012, at 11:53 , Brendan Eich wrote: Yes, so given the case Kevin raises of default-ful followed by default-less I agree with Kevin: length should reflect all but rest (if present). Allen, what built-ins would this break, do you know from checking what built-ins break under the current draft's rule? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.length and Default Parameters
One more question: are these optional parameters the kind that would want to use parameter default values if self-hosted? If so, that would cement the case for the current spec. Kevin's counter-example would be a it hurts when I do this! don't do it! thing. /be Norbert Lindenberg wrote: String.prototype.localeCompare Number.prototype.toLocaleString Date.prototype.toLocaleString Date.prototype.toLocaleDateString Date.prototype.toLocaleTimeString Intl.Collator Intl.Collator.supportedLocalesOf Intl.NumberFormat Intl.NumberFormat.supportedLocalesOf Intl.DateTimeFormat Intl.DateTimeFormat.supportedLocalesOf the function returned by Intl.DateTimeFormat.prototype.format ...are all specified in the ECMAScript Internationalization API Specification as taking optional arguments, but not counting them towards the value of their length properties. Norbert On Oct 12, 2012, at 11:53 , Brendan Eich wrote: Yes, so given the case Kevin raises of default-ful followed by default-less I agree with Kevin: length should reflect all but rest (if present). Allen, what built-ins would this break, do you know from checking what built-ins break under the current draft's rule? /be ___ 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: Map/Set.prototype.size
On Oct 12, 2012, at 12:14 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com wrote: Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the strawman. It appears in the latest draft, though weirdly enough Map.prototype.size is a function with an unused argument. What about making it an getter instead of a function? I guess we also don't need the extra parens to request for Map#keys, Map#values, Map#items. For keys, values and items I think they are cleaner as methods since they return a new iterator every time. Agreed. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
On Oct 12, 2012, at 9:38 AM, Kevin Smith khs4...@gmail.com wrote: The problem with explicit declarations is that it's going to be burdensome, for no apparent gain. Consider: I have a real-world class with 37 internal methods which are prefixed with an underscore. I'm not kidding. Explicit declaration means that I have to maintain a list of 37 at-name declarations, separate from the class definition itself, which contributes *no real information* that isn't available elsewhere in the module code. This is a strong point. My first instinct was similar to Axel's, but you're right that classes in particular tend to come with a lot of names. I still need to mull this. Thanks for this proposal. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
On Oct 12, 2012, at 12:45 PM, Kevin Smith khs4...@gmail.com wrote:
Also, I should mention a couple of things:
1. This design essentially paves the cowpath trod with underscore-prefixed
property names, adding the desired property of conflict elimination.
Yes, although I don't take the private, who needs it? attitude as easily as
you do. Not saying it's wrong, but I'm not 100% convinced yet. Anyway, still
mulling, as I say.
2. If System is a built-in *module instance*, and the @iterator symbol is
defined internally within that module as:
sym @iterator = org.ecma-whatever.es.6.iterator; // Or perhaps more
likely a uuid...
Then we have exactly the desired syntax that we're looking for:
import @iterator from System; // no funky @belch URLs!!
class C {
@iterator() { ... }
}
Doesn't this have the same problem you were arguing against in your previous
message, that if you want to import 37 names, you have to name them all
individually?
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
Yeah, just wasn't sure what I thought yet. Still not sure, but I've replied.
Dave
On Oct 12, 2012, at 2:22 PM, David Herman dher...@mozilla.com wrote:
On Oct 12, 2012, at 12:45 PM, Kevin Smith khs4...@gmail.com wrote:
Also, I should mention a couple of things:
1. This design essentially paves the cowpath trod with underscore-prefixed
property names, adding the desired property of conflict elimination.
Yes, although I don't take the private, who needs it? attitude as easily as
you do. Not saying it's wrong, but I'm not 100% convinced yet. Anyway, still
mulling, as I say.
2. If System is a built-in *module instance*, and the @iterator symbol is
defined internally within that module as:
sym @iterator = org.ecma-whatever.es.6.iterator; // Or perhaps more
likely a uuid...
Then we have exactly the desired syntax that we're looking for:
import @iterator from System; // no funky @belch URLs!!
class C {
@iterator() { ... }
}
Doesn't this have the same problem you were arguing against in your previous
message, that if you want to import 37 names, you have to name them all
individually?
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
WHOA. That appears to be a horrifying Apple mail bug. Not sure how my reply to
a private message ended up going to es-discuss, sorry.
Dave
On Oct 12, 2012, at 2:23 PM, David Herman dher...@mozilla.com wrote:
Yeah, just wasn't sure what I thought yet. Still not sure, but I've replied.
Dave
On Oct 12, 2012, at 2:22 PM, David Herman dher...@mozilla.com wrote:
On Oct 12, 2012, at 12:45 PM, Kevin Smith khs4...@gmail.com wrote:
Also, I should mention a couple of things:
1. This design essentially paves the cowpath trod with underscore-prefixed
property names, adding the desired property of conflict elimination.
Yes, although I don't take the private, who needs it? attitude as easily
as you do. Not saying it's wrong, but I'm not 100% convinced yet. Anyway,
still mulling, as I say.
2. If System is a built-in *module instance*, and the @iterator symbol
is defined internally within that module as:
sym @iterator = org.ecma-whatever.es.6.iterator; // Or perhaps more
likely a uuid...
Then we have exactly the desired syntax that we're looking for:
import @iterator from System; // no funky @belch URLs!!
class C {
@iterator() { ... }
}
Doesn't this have the same problem you were arguing against in your previous
message, that if you want to import 37 names, you have to name them all
individually?
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: Function.length and Default Parameters
Yes. Most of them take locales and options arguments, and those get eagerly
filled in with [] and {}, respectively. The last function takes a time value,
and defaults to Date.now().
Now, self-hosted functions have powers that others don't. In the SpiderMonkey
self-hosting environment, I can already specify per function whether they
should be constructors and whether they should have prototype objects. We may
be able to add a way to fake length values too.
More important: These functions were specified this way because TC 39 decided
that this is the direction for ES6, and even though ES5 style would have been
more convenient for us.
Norbert
On Oct 12, 2012, at 13:53 , Brendan Eich wrote:
One more question: are these optional parameters the kind that would want to
use parameter default values if self-hosted? If so, that would cement the
case for the current spec. Kevin's counter-example would be a it hurts when
I do this! don't do it! thing.
/be
Norbert Lindenberg wrote:
String.prototype.localeCompare
Number.prototype.toLocaleString
Date.prototype.toLocaleString
Date.prototype.toLocaleDateString
Date.prototype.toLocaleTimeString
Intl.Collator
Intl.Collator.supportedLocalesOf
Intl.NumberFormat
Intl.NumberFormat.supportedLocalesOf
Intl.DateTimeFormat
Intl.DateTimeFormat.supportedLocalesOf
the function returned by Intl.DateTimeFormat.prototype.format
...are all specified in the ECMAScript Internationalization API
Specification as taking optional arguments, but not counting them towards
the value of their length properties.
Norbert
On Oct 12, 2012, at 11:53 , Brendan Eich wrote:
Yes, so given the case Kevin raises of default-ful followed by default-less
I agree with Kevin: length should reflect all but rest (if present).
Allen, what built-ins would this break, do you know from checking what
built-ins break under the current draft's rule?
/be
___
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: Function.length and Default Parameters
Norbert Lindenberg wrote: More important: These functions were specified this way because TC 39 decided that this is the direction for ES6, and even though ES5 style would have been more convenient for us. I can't tell if you mean that Kevin's proposal would be adverse, helpful, or neutral. TC39 does change its mind before the spec is finalized; please don't mind that. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modular At-Names
Yes, although I don't take the private, who needs it? attitude as easily as you do. Not saying it's wrong, but I'm not 100% convinced yet. In a way I'm posing a challenge - I think it will be an interesting debate to have. Doesn't this have the same problem you were arguing against in your previous message, that if you want to import 37 names, you have to name them all individually? Sure, if we were inclined to import 37 names, but I don't think that will be the pattern. Look at current usage of underscored property names. Their usage is mostly confined to a single site (usually a class). Only occasionally will you find an underscored property name whose semantic origin is non-local (usually in class hierarchies). Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
