I would rather think about a smart syntax able to tell the function it
should expose arguments as it was before.

`function splice:arguments(start, deleteCount, ...items)`

or

`function splice:args(start, deleteCount, ...items)`

or anything different that looks reasonable ? Or maybe not useful at all as
Dmitry said (and I agree)


On Sun, Nov 10, 2013 at 11:47 AM, Mark S. Miller <erig...@google.com> wrote:

> Also
>
>     function f(args: x, y, z) {
>
> will suggest to TypeScript readers that the parameter "args" has type "x".
>
>
>
> On Sun, Nov 10, 2013 at 11:44 AM, Mark S. Miller <erig...@google.com>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.
>>
>> On these grounds, your
>>
>>     function f(args: x, y, z) {
>>
>> is worse. Given how ":" is already used in JS, this suggests that "args"
>> is either a label name, which the more astute reader can easily disqualify,
>> or a property name, suggesting some shorthand for named parameters.
>>
>> 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.
>>
>>
>>
>>
>> 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to