Newly revised Section 10 for ES3.1.

[Brendan Eich]

On Jul 10, 2008, at 4:02 PM, Richard Cornford wrote:

> A new specification probably should pin down which of these is  
> "correct".
> It should either reinforce the implication that the linkage is  
> intended to
> be long term or state the lifespan of the linkage (possibly saying  
> that it
> cannot be expected to hold past the lifespan of the execution  
> context for
> which the arguments object was created (thus categorizing longer term
> linkage as a possible non-standard extension)).

Hi Richard, thanks for bringing this to light. It's one of those  
implementation secrets I try to forget, and actually manage to forget  
sometimes. Indeed SpiderMonkey does not alias arguments[i] and the  
activation (variable) object property for the corresponding formal  
parameter after the underlying stack frame has been popped. This is  
old as the hills, and even goes back to the original Netscape 2  
("Mocha") runtime.


> I would favour the latter

I do too, and not simply because that's what Mozilla's implementation  
does (I don't know what Rhino does -- anyone?).

> as the inconsistency in existing implementations makes it unlikely  
> that
> anyone is using this linkage outside of the functions whose calls  
> create
> the arguments objects, and there is nothing that could be done with  
> this
> linkage that could not be better (less obscurely) achieved using  
> closures.

ES4 is actually deprecating the arguments object. To do this with any  
hope of being effective, we provide sweeter syntax without the  
aliasing cruft: optional (default value given in the function  
declaration) and rest parameters. Carrot, not stick.

I agree that specs should address this divergence of implementations  
from the ES3 (ES1, IIRC) language. Would you be willing to file a bug  
in the trac at http://bugs.ecmascript.org/ ? It would save me from  
copying and pasting your fine message, and you would get email  
notification of udpates to the ticket. Thanks,

/be