Iterating default function arguments
This is correct, because only one argument was passed, therefore the arguments object has only one entry. Parameters are not the same as Arguments.
Therefore:
foo(1, 3) => [1, 3]
Because two arguments were passed. And:
foo(1, 2, 3) => [1, 2, 3]
Because three were passed.
Hopefully that helps clarify?
I think the main concern was:
Currently I can't see a way of getting default parameters as an iterable object.
and indeed arguments is not the magic variable you are looking for.
However, you are inside your own defined function so either you don't
specify defaults, or you iterate over [a, b] ?
Interesting enough, there's no actually a way to understand the function signature, in terms of optionally accepted arguments.
arguments.length is one and same is for foo.length so if we'd like to
understand if anyone invoked the function passing or not all optional
parameters, how could we proceed?
Lets say foo would like to delegate its own arguments including defined
defaults to another function ... how can we grab these at runtime?
I think the answer is still a static [a, b] as list of arguments to
apply, but I can see some lack of "reflection" capability ... or maybe
Reflect would solve this?
Andrea Giammarchi wrote:
I think the answer is still a static
[a, b]as list of arguments to apply, but I can see some lack of "reflection" capability ... or maybe Reflect would solve this?
Yes, Reflect -- we want a mirror approach, not more magic object like arguments or function.
Sounds good to me and makes perfect sense. Robin?
I'm all for using Reflect, but looking at the API as listed on MDN, the harmony-reflect github, or the spec, i don't see an obvious way of getting the parameters.
tvcutsem/harmony-reflect/blob/master/doc/api.md
What am I missing?
I'm all for using Reflect, but looking at the API as listed on MDN, the harmony-reflect github, or the spec, i don't see an obvious way of getting the parameters.
If I understand you correctly (and this is not about parsing the parameter definitions) then how about the following solution?
function foo(...args) {
let [a, b = 2] = args;
return args;
}
Original code:
function foo( a, b = 2 ) {
return arguments;
}
Well my use case is for something I can insert into an existing function, in fact, a lot of functions, hopefully without manually listing the arguments.
function bar( parameters ) {
for ( var i = 0; i < parameters.length; i++ ) {
// do something interesting with each parameter of the function
}
}
function foo( a, b = 2 ) {
bar( parameters );
// do normal foo stuff
}
Thinking about it I can't see how Reflect could do this, because it's surely meant to be external to the function. For example with an imaginary Reflect.getParameters:
Reflect.getParameters( foo ) // could only give me [ a: undefined, b: 2 ] as reflect can't know what foo was called with from outside the function.
I was wondering if there were any plans to modify
argumentsto include default parameters (e.g. changing it from a simpleParameterList) or to include a new property that does allow iteration of all values available to a function.for example:
Currently I can't see a way of getting default parameters as an iterable object.
I filed a bug with Mozilla over this, but they pointed out that the behaviour matches the spec.
bugzilla.mozilla.org/show_bug.cgi?id=1144672
Hi there, I was wondering if there were any plans to modify `arguments` to include default parameters (e.g. changing it from a simpleParameterList) or to include a new property that does allow iteration of all values available to a function. for example: function foo( a, b = 2 ) { return arguments; } console.log( foo( 1 ) ); // outputs [ 1 ], not [ 1, 2 ] Currently I can't see a way of getting default parameters as an iterable object. I filed a bug with Mozilla over this, but they pointed out that the behaviour matches the spec. https://bugzilla.mozilla.org/show_bug.cgi?id=1144672 Regards, Robin On 25 March 2015 at 05:39, <es-discuss-request at mozilla.org> wrote: > Send es-discuss mailing list submissions to > es-discuss at mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > es-discuss-request at mozilla.org > > You can reach the person managing the list at > es-discuss-owner at mozilla.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: Object arithmetic--operator alternative to Object.assign > (Edwin Reynoso) > 2. Extended object literal property value shorthand (Bob Myers) > 3. Re: Extended object literal property value shorthand (Bob Myers) > > > ---------- Forwarded message ---------- > From: Edwin Reynoso <eorroe at gmail.com> > To: Rick Waldron <waldron.rick at gmail.com> > Cc: Bob Myers <rtm at gol.com>, es-discuss <es-discuss at mozilla.org> > Date: Tue, 24 Mar 2015 23:09:30 -0400 > Subject: Re: Object arithmetic--operator alternative to Object.assign > Yea, um I'm only 16 and been programming in Javascript for about 2-3 > years. I haven't gotten to the Nitty Gritty part of Javascript specs. So I > won't be able to help out with that. I was just throwing out what I > mentioned above. > > On Tue, Mar 24, 2015 at 10:39 PM, Rick Waldron <waldron.rick at gmail.com> > wrote: > >> >> >> On Tue, Mar 24, 2015 at 7:09 PM Edwin Reynoso <eorroe at gmail.com> wrote: >> >>> For different objects this is the only way I see possible with >>> destructuring. IMO it's a bit ugly and weird to read deep destructuring: >>> >>> ``` >>> let x = { a: 1 }; >>> let y = { b: 2 }; >>> let { x: { a }, y: { b } } = { x, y }; >>> ``` >>> >>> But I'd prefer Bob Myers's way: >>> >>> ``` >>> let x = { a: 1 }; >>> let y = { b: 2 }; >>> {x.a, y.b} >>> ``` >>> >>> Now that would be for destructuring. But isn't the following shorthand >>> property assignment not destructuring: >>> >>> ``` >>> var c = {x,y}; >>> >>> //so I'm thinking Bob wants the following: >>> >>> var c = {x.a, b.y}; // {a: 1, b: 2} >>> ``` >>> >> >> As an exercise to see if this is reasonable, I spent some time drafting >> an outline addition to "12.2.5.9 Runtime Semantics: >> PropertyDefinitionEvaluation" that handled a newly defined (ie. thing I >> made up) "PropertyDefinition : IdentifierNameReference", but ran into >> issues when I had to consider all the forms that MemberExpression includes. >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-left-hand-side-expressions >> >> >> >> >> Rick >> >> >> >> >>> >>> On Tue, Mar 24, 2015 at 3:51 PM, Tab Atkins Jr. <jackalmage at gmail.com> >>> wrote: >>> >>>> On Tue, Mar 24, 2015 at 9:44 AM, Bob Myers <rtm at gol.com> wrote: >>>> > Apologies if something like this has already been proposed. >>>> > >>>> > We have simplified object literal syntax: >>>> > >>>> > {a, b} >>>> > >>>> > However, I often find myself writing this: >>>> > >>>> > {a: x.a, b: y.b} >>>> > >>>> > Would it be possible to have a syntax such as >>>> > >>>> > {x.a, y.b} >>>> > >>>> > Where the property name is taken from the last segment of the property >>>> > reference, so that `x.a` becomes the value of property `a`? >>>> >>>> If you're taking both values from the *same* object, we have the syntax: >>>> >>>> {a, b} = x; >>>> >>>> This may or may not help you. >>>> >>>> ~TJ >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> > > > ---------- Forwarded message ---------- > From: Bob Myers <rtm at gol.com> > To: Rick Waldron <waldron.rick at gmail.com>, es-discuss < > es-discuss at mozilla.org> > Cc: > Date: Wed, 25 Mar 2015 09:08:16 +0530 > Subject: Extended object literal property value shorthand > Thanks Rick. Yes, I was hoping to make the following work: > > x = {a: 1}; > y = {b: 2}; > z = {x.a, b.y}; // {a: 1, b: 2} > > This is not destructuring, it's an extension to object literal property > value shorthand. > The idea is to derive the desired property name `a` from `x.a`. > However, it could be difficult to define when and how a property name > could be derived from various types of member expressions. > > Here is an alternative, admittedly not too pretty, but perhaps easier to > define and/or implement. The idea is to generalize the permissible > properties for which values can be omitted/inferred, and also allow LHS > destructuring-type syntax, so: > > x = {a: 1}; > y = {b: 2}; > > If I want to extract the two values using destructuring assignment today > we can do: > > var { x: {a}, y: {b} } = { x, y }; // a=1, b=2 > > Consider using the LHS destructuring syntax in the above as an expanded > shorthand property: > > z = { *{ x: {a}, y: {b} }* } // // {a: 1, b: 2} > > This kind of re-use of destructuring syntax would permit "renaming" > "on-the-fly": > > z = { { x: {a: A}, y: {b: B} } } // // {A: 1, B: 2} > > Or pulling things from arrays: > > q = [1, 2, 3]; > z = { { x: a, } } > > > erty" would be conceptually destructured into > > { x: {a}, y: {b} } > > z = { x: {a}, y: > > > > On Wed, Mar 25, 2015 at 8:09 AM, Rick Waldron <waldron.rick at gmail.com> > wrote: > >> >> >> On Tue, Mar 24, 2015 at 7:09 PM Edwin Reynoso <eorroe at gmail.com> wrote: >> >>> For different objects this is the only way I see possible with >>> destructuring. IMO it's a bit ugly and weird to read deep destructuring: >>> >>> ``` >>> let x = { a: 1 }; >>> let y = { b: 2 }; >>> let { x: { a }, y: { b } } = { x, y }; >>> ``` >>> >>> But I'd prefer Bob Myers's way: >>> >>> ``` >>> let x = { a: 1 }; >>> let y = { b: 2 }; >>> {x.a, y.b} >>> ``` >>> >>> Now that would be for destructuring. But isn't the following shorthand >>> property assignment not destructuring: >>> >>> ``` >>> var c = {x,y}; >>> >>> //so I'm thinking Bob wants the following: >>> >>> var c = {x.a, b.y}; // {a: 1, b: 2} >>> ``` >>> >> >> As an exercise to see if this is reasonable, I spent some time drafting >> an outline addition to "12.2.5.9 Runtime Semantics: >> PropertyDefinitionEvaluation" that handled a newly defined (ie. thing I >> made up) "PropertyDefinition : IdentifierNameReference", but ran into >> issues when I had to consider all the forms that MemberExpression includes. >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-left-hand-side-expressions >> >> >> >> >> Rick >> >> >> >> >>> >>> On Tue, Mar 24, 2015 at 3:51 PM, Tab Atkins Jr. <jackalmage at gmail.com> >>> wrote: >>> >>>> On Tue, Mar 24, 2015 at 9:44 AM, Bob Myers <rtm at gol.com> wrote: >>>> > Apologies if something like this has already been proposed. >>>> > >>>> > We have simplified object literal syntax: >>>> > >>>> > {a, b} >>>> > >>>> > However, I often find myself writing this: >>>> > >>>> > {a: x.a, b: y.b} >>>> > >>>> > Would it be possible to have a syntax such as >>>> > >>>> > {x.a, y.b} >>>> > >>>> > Where the property name is taken from the last segment of the property >>>> > reference, so that `x.a` becomes the value of property `a`? >>>> >>>> If you're taking both values from the *same* object, we have the syntax: >>>> >>>> {a, b} = x; >>>> >>>> This may or may not help you. >>>> >>>> ~TJ >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> > > > ---------- Forwarded message ---------- > From: Bob Myers <rtm at gol.com> > To: Rick Waldron <waldron.rick at gmail.com>, es-discuss < > es-discuss at mozilla.org> > Cc: > Date: Wed, 25 Mar 2015 09:09:09 +0530 > Subject: Re: Extended object literal property value shorthand > Hit send too soon, please ignore. > > On Wed, Mar 25, 2015 at 9:08 AM, Bob Myers <rtm at gol.com> wrote: > >> Thanks Rick. Yes, I was hoping to make the following work: >> >> x = {a: 1}; >> y = {b: 2}; >> z = {x.a, b.y}; // {a: 1, b: 2} >> >> This is not destructuring, it's an extension to object literal property >> value shorthand. >> The idea is to derive the desired property name `a` from `x.a`. >> However, it could be difficult to define when and how a property name >> could be derived from various types of member expressions. >> >> Here is an alternative, admittedly not too pretty, but perhaps easier to >> define and/or implement. The idea is to generalize the permissible >> properties for which values can be omitted/inferred, and also allow LHS >> destructuring-type syntax, so: >> >> x = {a: 1}; >> y = {b: 2}; >> >> If I want to extract the two values using destructuring assignment today >> we can do: >> >> var { x: {a}, y: {b} } = { x, y }; // a=1, b=2 >> >> Consider using the LHS destructuring syntax in the above as an expanded >> shorthand property: >> >> z = { *{ x: {a}, y: {b} }* } // // {a: 1, b: 2} >> >> This kind of re-use of destructuring syntax would permit "renaming" >> "on-the-fly": >> >> z = { { x: {a: A}, y: {b: B} } } // // {A: 1, B: 2} >> >> Or pulling things from arrays: >> >> q = [1, 2, 3]; >> z = { { x: a, } } >> >> >> erty" would be conceptually destructured into >> >> { x: {a}, y: {b} } >> >> z = { x: {a}, y: >> >> >> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150325/3fa2c111/attachment-0001.html>