Newly revised Section 10 for ES3.1.

Richard Cornford Richard at
Thu Jul 10 16:02:34 PDT 2008

> 10.1.8     Arguments Object
> For each non-negative integer, arg, less than the value of the
> length property, a property is created with name ToString(arg) and
> property attributes { [[Writable]]: true, [[Enumerable]]: false,
> [[Flexible]]: false }. The initial value of this property is the
> value of the corresponding actual parameter supplied by the caller.
> The first actual parameter value corresponds to arg = 0, the second
> to arg = 1, and so on. In the case when arg is less than the number
> of formal parameters for the Function object, this property shares
> its value with the corresponding property of the activation object.
> This means that changing this property changes the corresponding
> property of the activation object and vice versa.

The provision "that changing this property changes the corresponding 
property of the activation object and vice versa" implies a potentially 
long-term linkage between some properties of activation objects 
corresponding arguments object properties. As functions forming closures 
can have ongoing access to activation objects and references to arguments 
objects can be assigned to object properties and variables (and so remain 
accessible after the function calls for which they were created have 
finished) this implied long-term linkage could have practical 
implications. For example:-

function getToy(one, two, three){
    var ar = arguments;
    ar[2] = 7;
    return ({
            // setting the '0' property of the arguments object should
            // change the value of the - one - formal parameter.
            ar[0] = x;
            return one;
            two = x;
            return ar[1];
            return three;

var obj = getToy(1, 2, 3);


- could be expected to alert 5, 6 and 7, and does in Windows Safari 3 and 
Opera 9. But IE 6 and Firefox 2, for example, it alerts 1, 2 and 7. There 
the linkage breaks down outside of the execution context of the initial 
function call.

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)). I would favour the latter 
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.

More information about the Es4-discuss mailing list