What’s the best name for keyword parameters?
We don't have a proposal for named parameter passing in call expressions. Object literals take away all the oxygen in that room. WebIDL calls these dictionary parameters, IIRC.
I agree "keyword" is not the right word. Named parameters were part of original ES4/JS2:
We don't have a proposal for named parameter passing in call expressions. Object literals take away all the oxygen in that room. WebIDL calls these dictionary parameters, IIRC.
Yes, I agree and approve. Together with destructuring that is quite OK.
I agree "keyword" is not the right word.
Suggestions for better terms welcome. Property parameters? Inside a parameter object?
There is a long history of TC39 naming things for internal use and those names never escaping to the common lexicon. I'm not sure it's a thing we need to (or even should) weigh in on via the spec.
On Aug 3, 2012, at 6:55 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
We don't have a proposal for named parameter passing in call expressions. Object literals take away all the oxygen in that room. WebIDL calls these dictionary parameters, IIRC.
Yes, I agree and approve. Together with destructuring that is quite OK.
I agree "keyword" is not the right word.
Suggestions for better terms welcome. Property parameters? Inside a parameter object?
Named parameters were part of original ES4/JS2:
/be
Axel Rauschmayer wrote:
The term “keyword parameters” comes (AFAIK) from Lisp. I have seen Brendan use it and have also used it myself [1]. Can we do better? jQuery talks about “options objects”. Hence keyword parameter = option? But that clashes a bit with optional positional parameters.
-- Alex Russell slightlyoff at google.com slightlyoff at chromium.org alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
I agree. It would still be nice if we could find a common way of talking about this pattern (in the common lexicon). With the additional ES.next support, it is bound to become even more popular. It can feel like bikeshedding, but I think good naming matters. For example, I’m thankful for the term IIFE.
There is a long history of TC39 naming things for internal use and those names never escaping to the common lexicon. I'm not sure it's a thing we need to (or even should) weigh in on via the spec.
I agree. It would still be nice if we could find a common way of talking about this pattern (in the common lexicon). With the additional ES.next support, it is bound to become even more popular. It can feel like bikeshedding, but I think good naming matters. For example, I’m thankful for the term IIFE.
Ben Alman coined this, not the spec.
You are making my point!
Or are you saying that this kind of discussion (not directly related to the spec) is off-topic? But where else can you discuss this?
the world should call fat-arrow functions "rocket routines"
I think we have a winner.
I guess I'm just unclear about the motivation. I could say that the world should call fat-arrow functions "rocket routines", but then I'd be wrong if the spec still called them fat-arrow functions—regardless of whether or not I bothered to post it to es-discuss.
I stick to spec terminology as much as possible, but some things are beyond the scope of the spec (such as IIFE). Then I just want to make sure that there isn’t something good already in use before I make up my own words.
On Aug 6, 2012, at 2:23 PM, Rick Waldron wrote:
On Monday, August 6, 2012 at 4:57 PM, Axel Rauschmayer wrote:
There is a long history of TC39 naming things for internal use and those names never escaping to the common lexicon. I'm not sure it's a thing we need to (or even should) weigh in on via the spec.
I agree. It would still be nice if we could find a common way of talking about this pattern (in the common lexicon). With the additional ES.next support, it is bound to become even more popular. It can feel like bikeshedding, but I think good naming matters. For example, I’m thankful for the term IIFE.
Ben Alman coined this, not the spec.
You are making my point!
Or are you saying that this kind of discussion (not directly related to the spec) is off-topic? But where else can you discuss this? I think here is a fine place to discuss things like that, but they may not be relevant to the spec. IIFE is not a thing that is explicitly specified, but instead the product of combining 3 specified things: grouping, function expression and invocation. Prior to that they were commonly called "self executing anonymous function" which isn't even correct, let alone part of the spec.
I guess I'm just unclear about the motivation. I could say that the world should call fat-arrow functions "rocket routines", but then I'd be wrong if the spec still called them fat-arrow functions—regardless of whether or not I bothered to post it to es-discuss.
FWIW, the spec. currently calls these things "arrow functions".
The term “keyword parameters” comes (AFAIK) from Lisp. I have seen Brendan use it and have also used it myself [1]. Can we do better? jQuery talks about “options objects”. Hence keyword parameter = option? But that clashes a bit with optional positional parameters.
[1] www.2ality.com/2011/11/keyword-parameters.html