ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Jeff Dyer jodyer at adobe.com
Mon Mar 19 11:10:23 PDT 2007



> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-
> bounces at mozilla.org] On Behalf Of Vassily Gavrilyak
> Sent: Monday, March 19, 2007 3:21 AM
> To: Brendan Eich
> Cc: es4-discuss at mozilla.org; liorean
> Subject: Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix
> 
> On 3/19/07, Brendan Eich <brendan at mozilla.org> wrote:
> > On Mar 18, 2007, at 4:20 PM, Vassily Gavrilyak wrote:
> >
> > > Well, I sometimes get confused. It's very rare cases, but still
> > > happens to me. Don't remember any C-like language, but our cousin
> > > VBScript
> > > allows this. And those guys are sometimes confused too.
> > > Like here. http://www.thescripts.com/forum/thread91618.html
> >
> > Thanks, good information.
> >
> > > That's 'very corner' case, but why not just fix it, if the fix
will
> > > not break anything?
> >
> > You're certainly right that this is a syntactic extension that won't
> > break any existing code. Jeff Dyer should comment, since he's the
> > grammar owner and has good taste ;-).
> >
> > /be
> >
> >
> Thank you for considering this. While I can imagine why this
> functionality was disabled in ES1-3 (to protect programmer from
> misprints), in typed language typer could be responsible for handling
> this, not grammar.
> Well, let's wait for Jeff to comment.

I'm not sure the type system will help much since 'undefined' will
silently convert to a value of most types. An argument list with holes
looks like mistake to me. Why not force the user to say what he means?

> >Note also how arguments' type may not be Array, but something
> >delegating to Array.prototype. We need to finalize the spec, but
> >already ES1-3 makes arguments a magic type that aliases >arguments[0]
> >to a in function f(a){...}.
> So we have a magic that makes position->name transition for arguments.
> We also have destructuring magic. Shouldn't we go
> further and add desctructuring magic to function call too? This way we
> will get named arguments functionality, and that's something that
> adds readability to code in some cases.
> We can do emulate it right now (and I already do it) with hashes.
> But having this magic in language will help to optimize such calls and
> add readability.
> 
> Example
> 
> function Person(name, age){
>     this.name = name;
>     this.age     = age;
> }
> 
> Now I can use it like
> person = new Person("Joe", 20)
> 
> But much readable that I prefer to use is
> person = new Person(name:"Joe", age:20);
> 
> I can simulate this with
> person = new Person({name:"Joe", age:20})
> and pay performance penalty for readability,
> so my constructor will become something like this.
> 
> function Person(name, age){
>     if(typeof(name) == "object"){
>        var obj = name;
>         this.name = obj.name;
>         this.age = obj.age;
>     }else{
>        this.name = name;
>        this.age     = age;
>     }
> }
> 
> Again, not a big issue, but a little speed-up for correct and readable
> code will help.
> Probably named parameters were already considered, in this case I'm
> sorry for disturbing, just failed to find it in spec.

Named arguments has been discussed from time to time, but never had the
support to become a serious proposal. Both proposals here are future
proof and so I say let's hold off for now. We need to have something to
talk about when edition4 is done :) 

Any else think differently?

Jd



More information about the Es4-discuss mailing list