domenic at domenicdenicola.com (2013-11-15T18:50:17.023Z)
On Sun, Nov 10, 2013 at 1:08 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
> On Nov 10, 2013, at 12:53 PM, Mark S. Miller wrote:
>
> Does this become common for those using DOM APIs or for those implementing
> DOM APIs? If only the latter, well...
>
> I want to retire "arguments" as well. For these rare cases, I would use
> the patterns involving "...". Combining "..." with destructuring patterns
> in the body ain't too bad.
>
>
> A problem is that the implementation signature of an API is implemented is
> what is often document as the as the usage signature. So, if a lot of DOM
> APIs need to be implemented as function (...args) {
>
> then that is likely what will appear in documentation.
>
Generate the documentation from the WebIDL.
> Also note that there is likely to be actual computational overhead in both
> creating a rest argument and in destructuring it. In some cases, that
> overhead may be an issue.
>
When it is a performance cost, use arguments.length. I hate it, but less
than adding a new feature to the language merely to make an anti-pattern
more convenient.
> And introducing a new default binding that's implicitly in scope without
> explicit definition? C'mon Allen. "this", "arguments", "return", and
> "yield" already give programmers enough TCP refactoring hazards, such as
> when converting a for loop to a .forEach. How many red-flag identifiers
> must programmers scan for before undertaking this refactoring?
>
>
> that's why I suggested (...,#argCount)
> If you don't want to use new syntax then a built-in binding is a fallback
> solution.
>
I agree that #argCount is better than introducing a new builtin binding. #argCount is also better than being hit on the head with a hammer.
On Sun, Nov 10, 2013 at 1:08 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > > On Nov 10, 2013, at 12:53 PM, Mark S. Miller wrote: > > Does this become common for those using DOM APIs or for those implementing > DOM APIs? If only the latter, well... > > I want to retire "arguments" as well. For these rare cases, I would use > the patterns involving "...". Combining "..." with destructuring patterns > in the body ain't too bad. > > > A problem is that the implementation signature of an API is implemented is > what is often document as the as the usage signature. So, if a lot of DOM > APIs need to be implemented as function (...args) { > > then that is likely what will appear in documentation. > Generate the documentation from the WebIDL. > > Also note that there is likely to be actual computational overhead in both > creating a rest argument and in destructuring it. In some cases, that > overhead may be an issue. > When it is a performance cost, use arguments.length. I hate it, but less than adding a new feature to the language merely to make an anti-pattern more convenient. > > And introducing a new default binding that's implicitly in scope without > explicit definition? C'mon Allen. "this", "arguments", "return", and > "yield" already give programmers enough TCP refactoring hazards, such as > when converting a for loop to a .forEach. How many red-flag identifiers > must programmers scan for before undertaking this refactoring? > > > that's why I suggested (...,#argCount) > If you don't want to use new syntax then a built-in binding is a fallback > solution. > I agree that #argCount is better than introducing a new builtin binding. #argCount is also better than being hit on the head with a hammer. > > Allen > > > > > > > On Sun, Nov 10, 2013 at 12:42 PM, Allen Wirfs-Brock <allen at wirfs-brock.com > > wrote: > >> >> On Nov 10, 2013, at 11:44 AM, Mark S. Miller wrote: >> >> Hi Brendan and Allen, you are both responding only to my point #1. I >> consider my point #2 --- cognitive load of the reader on encountering a >> rarely seen construct --- to be the more significant criticism here. >> >> >> Hence my choice of using # which is more suggestive to the meaning. It >> seems suggestive enough that once somebody was initially exposed to it they >> would understand it when they say it. >> >> >> Note that I am not saying that the meanings of all syntactic constructs >> have to be guessable with no guidance. But the rarely used ones do. >> >> 3) Awkward syntax for some rarely used cases is the price of good syntax >> for common cases. >> >> >> But sometimes syntax to provide access to basic information or >> functionality that is rarely used. Arguably 'arguments' already provides >> such a hook but we are trying to generally discourage use of 'arguments' >> because of its other undesirable characteristics. >> >> A different alternative would be via a new default bind. We could >> specify that every function has an implicit const bind for 'actualArgCount' >> (unless there is a different explicit declaration for that name). >> >> As for rarity. I've been in enough long discussions with Web API folks >> on the public-script-coord list and on various WebIDL bugs to feel that >> this usage to define over-loads isn't that rare in the DOM API world. It >> would be nice for ES to have a story for handling such definitions other >> than falling back to using 'arguments' >> >> Allen >> >> >> >> >> >> >> >> On Sun, Nov 10, 2013 at 11:08 AM, Brendan Eich <brendan at mozilla.com>wrote: >> >>> On the other hand, we are this close in ES6 to relieveing people from >>> having to use arguments at all. >>> >>> I like the intention behind Allen's idea. To defend the concrete syntax >>> a bit, one would argue that only the final formal parameter may be prefixed >>> with #, and we are free to use # in other ways elsewhere. >>> >>> If # should be kept reserved even in this context, then perhaps >>> something like >>> >>> function f(args: x, y, z) { >>> // use x, y, z freely (they could be patterns) >>> switch (args.length) { >>> case 1: ... >>> case 2: ... >>> // etc. >>> } >>> } >>> >>> The "label" names a rest parameter for the entire parameter list. >>> >>> /be >>> >>>> Mark S. Miller <mailto:erights at google.com> >>>> November 10, 2013 6:52 PM >>>> >>>> 1) "#" is one of the few ascii characters we haven't used up yet. Let's >>>> not use it up on a minor convenience. >>>> >>>> 2) Introducing new syntax for use cases that are expected to be >>>> frequent, e.g., classes, often pays for its weight. The frequency makes it >>>> likely that readers will understand what it is the vast majority of times >>>> they encounter it. New syntax that gets used once in a blue moon can only >>>> be justified if the pain of doing without in those blue-moon cases is huge. >>>> In this case, it isn't. For those rare occasions when they see it, readers >>>> are much more likely to guess what "arguments.length" mean that this funny >>>> newfangled "#" thing. >>>> >>>> Code is read much more often than it is written -- at least code that >>>> matters. Brevity is useful as a metric only to the degree that it serves as >>>> a proxy for cognitive load on the reader. >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> --MarkM >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com> >>>> November 10, 2013 7:12 PM >>>> >>>> One of the the few remaining uses of a function's 'arguments' binding >>>> is to determine the actual number of passed arguments. This is necessary >>>> in some overloading scenarios where a function has different behavior when >>>> an argument is completely absent then it has when undefined (or any other >>>> default value) is explicitly passed in that parameter position. That >>>> situation occurs in a number of DOM APIs and even a few ES library >>>> functions. >>>> >>>> For example(see https://bugs.ecmascript.org/show_bug.cgi?id=1877 ), >>>> Array.prototype.splice returns different results for: >>>> [1,2,3].splice() >>>> and >>>> [1,2,3].splice(undefined) >>>> >>>> The natural ES6 declaration for a splice function is: >>>> >>>> function splice(start, deleteCount, ...items) {... >>>> >>>> but if you write it this way then within the body you have to have a >>>> test like: >>>> >>>> if (arguments.length == 0) {... >>>> >>>> to implement the correct web-compatable behavior. >>>> >>>> Or, alternatively you could declare the functions as: >>>> >>>> function splice(...actualArgs) { >>>> let [start, stop, ...item] = actualArgs; >>>> ... >>>> if (actualArgs.length == 0) {... >>>> >>>> So, to implement a Web-compaable version of splice you either have to >>>> use 'arguments' to determine the actual number of passed objects or you >>>> need to declare it with a bogus parameter pattern and use explicit or >>>> implicit destructuring to parse out the positional parameters. >>>> >>>> One way around this dilemma would be to provide a syntactic affordance >>>> for determing the actual argument count. For example, one possibility >>>> would be to allow the last item of any formal parameter list to be an item >>>> of the syntactic form: >>>> >>>> ActualArgumentCount : '#' BindingIdentifier >>>> >>>> So, the declaration for splice could then be: >>>> >>>> function splice(start, deleteCount, ...items, #argCount) { >>>> ... >>>> if (argCount == 0) {... >>>> >>>> Thoughts? >>>> >>>> Allen >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >> >> >> -- >> Cheers, >> --MarkM >> >> >> > > > -- > Cheers, > --MarkM > > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131110/63152644/attachment-0001.html>