For me (v8) it's more painful. As my code is an v8 extension, I don't have
access to the v8 internals, so I can't:
specify whether they should be constructors and whether they should have
prototype objects
Also, getting the length of the function to match 0, 1... is using lots of
argumens[0],
We made a decision about Function length and default parameters in the past and
I don't see a compelling reason to change that decision now.
The plan of record doesn't impact the node use case that Kevin identified as
they specify that 4 non-optional parameters are required and we aren't making
Allen Wirfs-Brock wrote:
We made a decision about Function length and default parameters in the
past and I don't see a compelling reason to change that decision now.
I'm ok with that, so (IEEE754 nod): +0.
The plan of record doesn't impact the node use case that Kevin
identified as they
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
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
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
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
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
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
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:
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
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:
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,
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
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
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
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
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
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
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
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:
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
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.
On Wed, Oct 10, 2012 at 1:22 PM, Kevin Smith khs4...@gmail.com wrote:
We've discussed this extensively before and there doesn't seem to be many
plausible use cases for the function length property.
Here's the only use case that I've encountered (admittedly not
particularly strong):
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
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
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
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
ExpectedArgumentCount is used to the the length property of function objects.
We've discussed this extensively before and there doesn't seem to be many
plausible use cases for the function length property.
Given that length isn't very useful alignment with the conventions used for the
We've discussed this extensively before and there doesn't seem to be many
plausible use cases for the function length property.
Here's the only use case that I've encountered (admittedly not particularly
strong): Overriding the behavior of a function/method based on the
signature of an input
30 matches
Mail list logo
