On Nov 10, 2013, at 1:08 PM, Allen Wirfs-Brock 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.
>
> 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.
I think I'm with Mark here, and as mentioned, don't think spreading two
equivalent ways of doing the same thing (`args.length` and #count in case when
have only the `...args`) is the best design decision.
Yes, it's true that destructuring could make some overhead, but no one is tight
to use it: a var-args function still can be described as `...args` only and
check its length as it does with the `arguments`.
Moreover, for this particular `splice` example, I don't think the `(start,
deleteCount, ...rest)` is the best signature (not to say, incorrect signature).
As again was mentioned, a var-args function seems should just use the `...rest`
params, and exactly starting from the position when the first optional argument
is started. And if it's started right from the position 0 (as with the
`splice`), then probably the more natural signature would be the `(...args)`.
P.S.: I do also agree that it's better to reserve the syntax of `(foo: bar)`
for the optional types (that are used in TypeScript now).
Dmitry
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
