quirky arguments

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

quirky arguments

Hallvord Reiar Michaelsen Steen-3
Question from a blog post (URL below):

Here is the issue in a minimal snippet of JavaScript:

function test(){}
test.arguments='something';
test();
alert(test.arguments); // test.arguments is now null ??

The local variable called "arguments" also becomes a property of the  
function itself, and is subsequently reset to null. Consider

function test(){ alert(arguments==test.arguments); }

which says "true" and shows us that the local variable and the function  
property refer to the same object.

Some side-effects of this implementation include:

"arguments" is a reserved word as function property name, it can not be  
used (this isn't documented AFAIK)

We can work out whether a function has been called by a script or not!  
Consider
Function.prototype.arguments=true;
function test(){};
.
. /* function definitions and calls here */
.
var testWasCalled = ! test.arguments;

"testWasCalled" is now true if and only if the script has used the "test"  
function during its execution. Might be a handy trick for trying to  
optimise large scripts

..but where in the ECMA-262 spec is this specified?
In other words, is it a (cross-browser) bug or a feature?

<URL: http://my.opera.com/hallvors/blog/2007/01/22/quirky-arguments >

--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience


Reply | Threaded
Open this post in threaded view
|

Re: quirky arguments

liorean
On 1/22/07, Hallvord R. M. Steen <[hidden email]> wrote:
> ..but where in the ECMA-262 spec is this specified?
> In other words, is it a (cross-browser) bug or a feature?

Well, IIRC Netscape exposed the arguments object as a property on
function objects as well as a local variable. In fact, you could
access the local variables and arguments by name as properties on the
function object, if I'm not mistaken.

So, this might be some kind of backwards compatibility feature.

According to MDC, arguments as a property of the function object was
deprecated in JavaScript 1.4.
<uri:http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions:arguments>
--
David "liorean" Andersson

Reply | Threaded
Open this post in threaded view
|

Re: quirky arguments

Lars T Hansen-2
In reply to this post by Hallvord Reiar Michaelsen Steen-3
> Question from a blog post (URL below):
>
> Here is the issue in a minimal snippet of JavaScript:
>
> function test(){}
> test.arguments='something';
> test();
> alert(test.arguments); // test.arguments is now null ??
>
> The local variable called "arguments" also becomes a property of the
> function itself, and is subsequently reset to null. Consider
>
> function test(){ alert(arguments==test.arguments); }
>
> which says "true" and shows us that the local variable and the function
> property refer to the same object.
>
> Some side-effects of this implementation include:
>
> "arguments" is a reserved word as function property name, it can not be
> used (this isn't documented AFAIK)
>
> We can work out whether a function has been called by a script or not!
> Consider
> Function.prototype.arguments=true;
> function test(){};
> .
> . /* function definitions and calls here */
> .
> var testWasCalled = ! test.arguments;
>
> "testWasCalled" is now true if and only if the script has used the "test"
> function during its execution. Might be a handy trick for trying to
> optimise large scripts
>
> ..but where in the ECMA-262 spec is this specified?
> In other words, is it a (cross-browser) bug or a feature?
>
> <URL: http://my.opera.com/hallvors/blog/2007/01/22/quirky-arguments >

"functionobject.arguments" is not defined in ECMA-262, though obviously
the local "arguments" variable is (section 10.1.6).

Unlike what you say (or perhaps only imply by use of ambiguous grammar?),
I don't think it's testable whether the "arguments" variable is ever reset
to null.

("functionobject.arguments" can be hard to implement efficiently and its
impact on program maintainability is IMHO solidly negative, but since it's
on the web it's probably with us until people start writing ecma4 "strict"
code as a matter of habit :-)

--lars