# Function length

24 messages
12
Open this post in threaded view
|

## Function length

 I just noticed strange behavior in spider monkey implementation of rest arguments: (function(a, b, ...rest) {}).length // => 2I think ignoring `rest` in length is pretty counter intuitive. For example I have small utility function thatI use to dispatch depending on argument length.var sum = dispatcher([  function() { return 0 },  function(x) { return x },  function(x, y) { return x + y },  function(x, y, z) { return Array.prototype.slice.call(arguments, 1).reduce(sum, x) }])  This behavior of rest would obviously break assumptions made by this library. That being said I don't think `3` would be any better. Maybe such functions length should be:- Infinity ?- 2.5 ?That way libraries would be able to handle them in a nice way:var sum = dispatcher([  () => 0,  (x) => x,  (x, y) => x + y,  (x, ...rest) => rest.reduce(sum, x)])Regards--Irakli Gozalishvili _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 Don't you want to use arguments.length instead of function.length? On Jun 9, 2012 6:53 PM, "Irakli Gozalishvili" <[hidden email]> wrote: I just noticed strange behavior in spider monkey implementation of rest arguments: (function(a, b, ...rest) {}).length // => 2 I think ignoring `rest` in length is pretty counter intuitive. For example I have small utility function thatI use to dispatch depending on argument length. var sum = dispatcher([  function() { return 0 },  function(x) { return x },   function(x, y) { return x + y },  function(x, y, z) { return Array.prototype.slice.call(arguments, 1).reduce(sum, x) }])  This behavior of rest would obviously break assumptions made by this library. That being said I don't think `3` would be any better. Maybe such functions length should be: - Infinity ?- 2.5 ?That way libraries would be able to handle them in a nice way: var sum = dispatcher([  () => 0,  (x) => x,   (x, y) => x + y,  (x, ...rest) => rest.reduce(sum, x)]) Regards--Irakli Gozalishvili _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 On Saturday, June 9, 2012 at 11:53 PM, Erik Arvidsson wrote: Don't you want to use arguments.length instead of function.length? On Jun 9, 2012 6:53 PM, "Irakli Gozalishvili" <[hidden email]> wrote: I just noticed strange behavior in spider monkey implementation of rest arguments: (function(a, b, ...rest) {}).length // => 2I agree that this is strange, I would expect 3, as there are three formally named parameters. Rick  I think ignoring `rest` in length is pretty counter intuitive. For example I have small utility function thatI use to dispatch depending on argument length. var sum = dispatcher([  function() { return 0 },  function(x) { return x },   function(x, y) { return x + y },  function(x, y, z) { return Array.prototype.slice.call(arguments, 1).reduce(sum, x) }])  This behavior of rest would obviously break assumptions made by this library. That being said I don't think `3` would be any better. Maybe such functions length should be: - Infinity ?- 2.5 ?That way libraries would be able to handle them in a nice way: var sum = dispatcher([  () => 0,  (x) => x,   (x, y) => x + y,  (x, ...rest) => rest.reduce(sum, x)]) Regards--Irakli Gozalishvili _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________es-discuss mailing list[hidden email]https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 On Sat, Jun 9, 2012 at 9:08 PM, Rick Waldron <[hidden email]> wrote: > I just noticed strange behavior in spider monkey implementation of rest > arguments: > > (function(a, b, ...rest) {}).length // => 2 > > I agree that this is strange, I would expect 3, as there are three formally > named parameters. The length in ES5 is not very consistent. For ES6 we decide that we wanted the function length to be used to tell how many required parameters a function has. Today rest params are done using arguments: (function(a, b) {   var rest = Array.prototype.slice.call(arguments, 2); }).length  // => 2 The rule is that optional and rest parameters are not included in the length of the function. -- erik _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 In reply to this post by Irakli Gozalishvili On Jun 9, 2012, at 6:52 PM, Irakli Gozalishvili wrote: I just noticed strange behavior in spider monkey implementation of rest arguments: (function(a, b, ...rest) {}).length // => 2That answer is consistent with what is specified in the ES6 draft spec.  The actual value is specified algorithmically  and is summarized by this note: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.See section 13.1.The draft is based upon the conclusions that were reached when this was last discussed.  See the thread starting https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html There is no obviously "right" answer to what should be reported as the length (and it isn't clear whether this property really has any utility).  The closest thing we have to legacy precedent are these statement from previous versions of the spec:15 Every built-in Function object described in this clause—whether as a constructor, an ordinary function, or both—has a length property whose value is an integer. Unless otherwise specified, this value is equal to the largest number of named arguments shown in the subclause headings for the function description, including optional parameters.15.3.5.1 The value of the length property is an integer that indicates the “typical” number of arguments expected by the function.Note that that the the legacy description is not particularly self consistent and that where a length value is "other specified" for various built-in functions it tends to follow the 15.3.5.1 rule.Allen_______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 Never the less problem still stands, but maybe there are other ways to solve it. Only solution I'm left with so far is utility function like this: function hasRest(f) {  return !!~String(f).split('\n').shift().indexOf('...')}Which is bad, specially toString of function is not guaranteed to return source.Maybe alternative solution could be some standard function / method to test if the function captures ...rest args. Regards--Irakli Gozalishvili On Saturday, 2012-06-09 at 23:54 , Allen Wirfs-Brock wrote: On Jun 9, 2012, at 6:52 PM, Irakli Gozalishvili wrote: I just noticed strange behavior in spider monkey implementation of rest arguments: (function(a, b, ...rest) {}).length // => 2That answer is consistent with what is specified in the ES6 draft spec.  The actual value is specified algorithmically  and is summarized by this note: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.See section 13.1.The draft is based upon the conclusions that were reached when this was last discussed.  See the thread starting https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html There is no obviously "right" answer to what should be reported as the length (and it isn't clear whether this property really has any utility).  The closest thing we have to legacy precedent are these statement from previous versions of the spec:15 Every built-in Function object described in this clause—whether as a constructor, an ordinary function, or both—has a length property whose value is an integer. Unless otherwise specified, this value is equal to the largest number of named arguments shown in the subclause headings for the function description, including optional parameters.15.3.5.1 The value of the length property is an integer that indicates the “typical” number of arguments expected by the function.Note that that the the legacy description is not particularly self consistent and that where a length value is "other specified" for various built-in functions it tends to follow the 15.3.5.1 rule.Allen _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 On Sun, Jun 10, 2012 at 12:48 PM, Irakli Gozalishvili wrote: Never the less problem still stands, but maybe there are other ways to solve it. Only solution I'm left with so far is utility function like this: function hasRest(f) {  return !!~String(f).split('\n').shift().indexOf('...') }Which is bad, specially toString of function is not guaranteed to return source. Maybe alternative solution could be some standard function / method to test if the function captures ...rest args.You could imagine a method like Function.prototype.hasRestArgs, but that wouldn't catch the existing varargs-style coding based on arguments. -- John A. TamplinSoftware Engineer (GWT), Google _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 In reply to this post by Irakli Gozalishvili On 10 June 2012 03:52, Irakli Gozalishvili <[hidden email]> wrote: > I just noticed strange behavior in spider monkey implementation of rest > arguments: > > (function(a, b, ...rest) {}).length // => 2 > > I think ignoring `rest` in length is pretty counter intuitive. For example I > have small utility function that > I use to dispatch depending on argument length. > > var sum = dispatcher([ >   function() { return 0 }, >   function(x) { return x }, >   function(x, y) { return x + y }, >   function(x, y, z) { return Array.prototype.slice.call(arguments, > 1).reduce(sum, x) } > ]) I don't think any library should ever rely on f.length. It is not a reliable source of information (f might use 'arguments' even when the length is officially 0), and I don't honestly see it being useful for anything but tertiary debugging purposes. /Andreas _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 I don't think any library should ever rely on f.length. That's a wrong  attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful & IMO should  be deprecated / removed.  It is not areliable source of information (f might use 'arguments' even when thelength is officially 0), and I don't honestly see it being useful foranything but tertiary debugging purposes.In some cases weather function captures `rest` arguments via `arguments` is irrelevant. Like in a case I've pointed out earlier. Library provides arity based dispatch based on f.length, so if you pass `function() { arguments…. }` it will never be called with more than 0 arguments.Regards--Irakli Gozalishvili On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote: On 10 June 2012 03:52, Irakli Gozalishvili <[hidden email]> wrote:I just noticed strange behavior in spider monkey implementation of restarguments:(function(a, b, ...rest) {}).length // => 2I think ignoring `rest` in length is pretty counter intuitive. For example Ihave small utility function thatI use to dispatch depending on argument length.var sum = dispatcher([  function() { return 0 },  function(x) { return x },  function(x, y) { return x + y },  function(x, y, z) { return Array.prototype.slice.call(arguments,1).reduce(sum, x) }])I don't think any library should ever rely on f.length. It is not areliable source of information (f might use 'arguments' even when thelength is officially 0), and I don't honestly see it being useful foranything but tertiary debugging purposes./Andreas _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote: I don't think any library should ever rely on f.length. That's a wrong  attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful & IMO should  be deprecated / removed. Let me try again.  We don't understand your use case.  You didn't show us the definition of your dispatch function so we have to guess.  Even so, It is hard to imagine a "legitimate" use with dynamically provided functions, particularly as the length values assigned to the existing built-ins don't follow strict rules. At the very least you need to help us understand why your use case is both reasonable and valid.Allen_______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 In reply to this post by Irakli Gozalishvili I would not mind removing Function 'length' but on the web you cannot deprecate and any browser daring to remove will appear broken to users not involved in the content or the engine, and users switch browsers. Anyway, back to reality: foo.length is in ECMA-262 and we need to spec how it works in the presence of a trailing rest parameter. Allen has drafted something based on discussion here. It's a plausible design and hard to criticize without both your use-case (in detail) and a better alternative. /be Irakli Gozalishvili wrote: >> I don't think any library should ever rely on f.length. > > That's a wrong  attitude, there always will be legitimate uses of any > feature, otherwise such features are just harmful & IMO should  be > deprecated / removed. > >> It is not a >> reliable source of information (f might use 'arguments' even when the >> length is officially 0), and I don't honestly see it being useful for >> anything but tertiary debugging purposes. > > In some cases weather function captures `rest` arguments via > `arguments` is irrelevant. Like in a case I've pointed out earlier. > Library provides arity based dispatch based on f.length, so if you > pass `function() { arguments…. }` it will never be called with more > than 0 arguments. > > Regards > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/> > On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote: > >> On 10 June 2012 03:52, Irakli Gozalishvili <[hidden email] >> > wrote: >>> I just noticed strange behavior in spider monkey implementation of rest >>> arguments: >>> >>> (function(a, b, ...rest) {}).length // => 2 >>> >>> I think ignoring `rest` in length is pretty counter intuitive. For >>> example I >>> have small utility function that >>> I use to dispatch depending on argument length. >>> >>> var sum = dispatcher([ >>>   function() { return 0 }, >>>   function(x) { return x }, >>>   function(x, y) { return x + y }, >>>   function(x, y, z) { return Array.prototype.slice.call(arguments, >>> 1).reduce(sum, x) } >>> ]) >> >> I don't think any library should ever rely on f.length. It is not a >> reliable source of information (f might use 'arguments' even when the >> length is officially 0), and I don't honestly see it being useful for >> anything but tertiary debugging purposes. >> >> /Andreas > > _______________________________________________ > es-discuss mailing list > [hidden email] > https://mail.mozilla.org/listinfo/es-discuss_______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 In reply to this post by Allen Wirfs-Brock Sorry for not being clear about this. Here is a simplified example of the implementation:https://gist.github.com/2911817 Also this is just a single particular example, but I expect there to be more. I think what I'mreally asking for is a way to know if …rest is being used.Also IMO arrow functions should not have `arguments` at all.  Regards--Irakli Gozalishvili On Monday, 2012-06-11 at 11:04 , Allen Wirfs-Brock wrote: On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote: I don't think any library should ever rely on f.length. That's a wrong  attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful & IMO should  be deprecated / removed. Let me try again.  We don't understand your use case.  You didn't show us the definition of your dispatch function so we have to guess.  Even so, It is hard to imagine a "legitimate" use with dynamically provided functions, particularly as the length values assigned to the existing built-ins don't follow strict rules. At the very least you need to help us understand why your use case is both reasonable and valid.Allen _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Function length

 In reply to this post by Brendan Eich-2 I find Function 'length' as very useful property (I use it in some low-level functional stuff). I also think that defining functions so it reflects only required arguments is very sane decision. In that light I would also expect ...rest to not be counted in Function length. +1 for keeping it, the way it is. Brendan Eich-2 wrote I would not mind removing Function 'length' but on the web you cannot deprecate and any browser daring to remove will appear broken to users not involved in the content or the engine, and users switch browsers. Anyway, back to reality: foo.length is in ECMA-262 and we need to spec how it works in the presence of a trailing rest parameter. Allen has drafted something based on discussion here. It's a plausible design and hard to criticize without both your use-case (in detail) and a better alternative. /be Irakli Gozalishvili wrote: >> I don't think any library should ever rely on f.length. > > That's a wrong  attitude, there always will be legitimate uses of any > feature, otherwise such features are just harmful & IMO should  be > deprecated / removed. > >> It is not a >> reliable source of information (f might use 'arguments' even when the >> length is officially 0), and I don't honestly see it being useful for >> anything but tertiary debugging purposes. > > In some cases weather function captures `rest` arguments via > `arguments` is irrelevant. Like in a case I've pointed out earlier. > Library provides arity based dispatch based on f.length, so if you > pass `function() { arguments…. }` it will never be called with more > than 0 arguments. > > Regards > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/> > On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote: > >> On 10 June 2012 03:52, Irakli Gozalishvili > > wrote: >>> I just noticed strange behavior in spider monkey implementation of rest >>> arguments: >>> >>> (function(a, b, ...rest) {}).length // => 2 >>> >>> I think ignoring `rest` in length is pretty counter intuitive. For >>> example I >>> have small utility function that >>> I use to dispatch depending on argument length. >>> >>> var sum = dispatcher([ >>>   function() { return 0 }, >>>   function(x) { return x }, >>>   function(x, y) { return x + y }, >>>   function(x, y, z) { return Array.prototype.slice.call(arguments, >>> 1).reduce(sum, x) } >>> ]) >> >> I don't think any library should ever rely on f.length. It is not a >> reliable source of information (f might use 'arguments' even when the >> length is officially 0), and I don't honestly see it being useful for >> anything but tertiary debugging purposes. >> >> /Andreas > > _______________________________________________ > 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
Open this post in threaded view
|

## Re: Function length

Open this post in threaded view
|

## Re: Function length

Open this post in threaded view
|

## Re: Function length

Open this post in threaded view
|

## Re: Function length

Open this post in threaded view
|

## Re: Function length

Open this post in threaded view
|