The last paragraph of section 10.1.8 of the proposed ES 3.1 specification currently reads:-
10.1.8 Arguments Object
...
... 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 ({
setOne:function(x){
// setting the '0' property of the arguments object should
// change the value of the - one - formal parameter.
ar[0] = x;
},
getOne:function(){
return one;
},
setTwo:function(x){
two = x;
},
getTwo:function(){
return ar[1];
},
getThree:function(){
return three;
}
});
}
var obj = getToy(1, 2, 3);
obj.setOne(5);
obj.setTwo(6);
alert(
obj.getOne()+'\n'+
obj.getTwo()+'\n'+
obj.getThree()
);
- could be expected to alert 5, 6 and 7, and does in Windows Safari 3 and
Opera 9. But in 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.
