s/named arguments/named parameters :)
-
-
Replying to @getify
Is there an important reason for your distinction here? I was using the terminology from the spec chapter 17 "Unless otherwise specified, this value is equal to the largest number of named arguments..."
1 reply 0 retweets 0 likes -
Replying to @briankardell
This is the commonly accepted distinction between the two terms:pic.twitter.com/u7Ce5hn3O1
2 replies 0 retweets 4 likes -
Replying to @getify @briankardell
Moreover, a "named argument" is a different thing entirely, in that in several languages (Scala, Obj-C, and even idiomatically JS), you can "name your arguments" at the call-site and have those mapped to params. for example: foo(someParam = 3, otherParam = 2);
1 reply 0 retweets 1 like -
Replying to @getify @briankardell
in JS, we do that idiomatically with object literals and object param destructuring: function foo({ someParam, otherParam }) { .. } // named params foo({ otherParam: 2, someParam: 3 }); // named args
2 replies 0 retweets 4 likes -
Replying to @getify @briankardell
Counterargument: the arguments object
2 replies 0 retweets 0 likes -
Replying to @mathias @briankardell
actually, I think the `arguments` object is a confirmation of these. The `arguments` object/array holds all the values that were passed in as **arguments**. It's a very nuanced and frowned-upon strange'ness that there's a deep reference from the arguments entry to the param.
2 replies 0 retweets 2 likes -
I always teach it this way, that the `arguments` array is holding the argument values, irrespective of any params which also might be holding them by name.
1 reply 0 retweets 1 like -
Replying to @getify @briankardell
That explanation breaks down in the face of the shadowing behavior. function foo(a, b) { a = 9; b = 8; console.log(arguments); } foo(1, 2);
1 reply 0 retweets 1 like -
Replying to @mathias @briankardell
I know about the shadowing and I mentioned it in my earlier tweet ("...deep reference..."). but i think my assertion stands, given that nobody in their right mind uses that intentionally, and strict mode eliminated it. I'd wager > 99% have never even heard of or considered it.
3 replies 0 retweets 2 likes
And now you have to explain what “deep reference” means. It’s not accurate; it’s not a reference to the original values that were passed, nor to their bindings, as the example shows. Just seems easier to use the terminology that’s in the language instead of mixing things up.
-
-
Replying to @mathias @briankardell
I don't understand what your arguing about here? I used "deep reference" as a quick abbr while tweeting. I don't teach the actual topic at all anymore, as I already said, so what I call it in tweets is not terribly relevant.
1 reply 0 retweets 0 likes -
I wouldn't use "shadowing" either, as that is also confusing. Typically "shadowing" is used to describe variables of the same name in different scopes, or properties of the same name on different links in the prototype chain. That's not what this is.
1 reply 0 retweets 1 like - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.