On Sep 27, 2012, at 10:03 AM, Oliver Hunt wrote:
>
> On Sep 27, 2012, at 9:45 AM, David Bruant <bruan...@gmail.com> wrote:
>
>> ...this is how I discovered that, in non-strict mode, it's possible to
>> define a function where 2 arguments have the same name...
>>
>> Le 27/09/2012 18:19, Allen Wirfs-Brock a écrit :
>>> Consider
>>>
>>> function f(a, b=a, a=3, c=a) {
>> The most positive adjective I can find to describe this like is:
>> "confusing".
>> If I'm ever in a team where a dev writes such a line, I will kill this
>> dev with my bare hands :-)
>> When writing 'c=a', what was the intention of the developer? Maybe the
>> third arg has been renamed to 'a' by mistake during a refactoring,
>> introducing a subtle bug.
>>
>> When using the same argument name several times with default values,
>> what about throwing an SyntaxError at parse time regardless of
>> strictness? It would follow what's been done with strict mode.
>
>
> I actually like this, it simplifies the semantics if you say using default
> arguments disallows duplicate names. This I think is a livable restriciton
> as allowing duplicate arguments is basically just a backwards compat feature
> (so obviously doesn't effect code using defaults).
>
> I kind of like the idea of disallowing shadowing of argument names if
> defaults are used as well, but I'm not sure if that would be as low risk to
> comprehension of behavior.
My original intent was to apply such rules and the current spec. draft actually
has some of these restrictions. However, those parts were written before 1JS
emerged and the consensus around 1JS seems to be try to gracefully extend the
current ES5 semantics to encompass such new feature without early error
restrictions.
Also, at the last meeting there was some significant push back about the
load-time costs (startup latency) of early error detection.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
