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.

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?



On Sun, Nov 10, 2013 at 12:42 PM, Allen Wirfs-Brock
<al...@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 <bren...@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:erig...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>> Allen Wirfs-Brock <mailto:al...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
>
>


-- 
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to