«

I'm currently writing a JS->Scheme compiler (which, using Bigloo,
automatically yields a JS->C, JS->JVM, JS->.NET compiler), and have a
question concerning the function-parameters:
According to the spec (10.1.6) the activation-object already contains the
the parameters-object when the variables are instantiated (10.1.3). The
question is now: does a parameter "parameters" overwrite the
"parameters"-object or not?
All three implementations I tested (Konqueror, Mozilla and Rhino) do not
overwrite the object, but I've already seen all three fail on other simple
examples.
Here's a minimal example:
===
function g(parameters) {
alert(arguments.length);
}
g({length:"object"}); // => "object"? 1?
===
// florian loitsch

Florian Loitsch wrote:

> function g(parameters) {
> alert(arguments.length);
> }
> g({length:"object"}); // => "object"? 1?

1.

In your function "g", either "parameters", or "arguments[0]",
but not "arguments" would reference the anonymous object you
supplied as the first argument.

ciao, dhgm

Obviously I was tired when I wrote this test case...
replace all "parameters" with "arguments" in my post.
-> question becomes:
===
function g(arguments) {
alert(arguments.length);
}
g({length:"object"}); // "object"? or 1?
===

and in this case Konqueror, Rhino as well as Mozilla return "object" (what I
expect it to be, eventhough I'm not completely sure, if it is defined in
the spec).
sorry for the typo...
// florian loitsch

Florian Loitsch wrote:

[snip]

> ===
> function g(arguments) {
> alert(arguments.length);
> }
> g({length:"object"}); // "object"? or 1?
> ===
>
> and in this case Konqueror, Rhino as well as Mozilla return
> "object" (what I expect it to be, eventhough I'm not completely
> sure, if it is defined in the spec).

The specification implies the order in section 10.1.6 - Activation Object:

"When control enters an execution context for function code, an
object called the activation object is created and associated
with the execution context. The activation object is initialised
with a property with name arguments and attributes
{ DontDelete }. The initial value of this property is the
arguments object described below.

The activation object is then used as the variable object for
the purposes of variable instantiation."

The activation object is initialised with the arguments property,
after which the same object is used for variable instantiation. As the
arguments property does not possess the ReadOnly attribute, it is safe
to assume that any local variable that is instantiated with the same
name should overwrite the arguments object. Also notice the use of the
phrase "initial value", which implies that the arguments property can
take on another value.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Michael Winter wrote:

> As the
> arguments property does not possess the ReadOnly attribute, it is safe
> to assume that any local variable that is instantiated with the same
> name should overwrite the arguments object.

It does not really overwrite the arguments object, it just assigns
another reference to the execution context's property "arguments".
The arguments object is still accessible via
g[0]..g[g.lenght-1] in Gecko based browsers and via
g.arguments[0]..g.arguments[g.length-1] in MSIE (if the function's
identifier is "g").

ciao, dhgm

Dietmar Meier wrote:

> Michael Winter wrote:
>
>> [...] any local variable that is instantiated with the same name
>> should overwrite the arguments object.
>
> It does not really overwrite the arguments object, [...]

Yes, it does.

function testArguments() {
var arguments = 'string';

alert(arguments + ' ' + testArguments.arguments);
}

The alert will contain the text, string, twice not once followed by
the toString result of the arguments object.

Though this behaviour might not be what one would expect with regard
to object references, it is what happens with respect to the arguments
object.

> The arguments object is still accessible [as a property of the
> function]

As I just demonstrated, it isn't. Moreover, that approach is
deprecated as of JS1.4 and is not present in the ECMAScript standard.
Why should it be? It's not necessary.

If you want to access the arguments object, don't create a local
variable (of any origin) with the same name.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Michael Winter wrote:

> Florian Loitsch wrote:
>
> [snip]
>
>> ===
>> function g(arguments) {
>> alert(arguments.length);
>> }
>> g({length:"object"}); // "object"? or 1?
>> ===
>>
[SNIP]
>
> The activation object is initialised with the arguments property,
> after which the same object is used for variable instantiation. As the
> arguments property does not possess the ReadOnly attribute, it is safe
> to assume that any local variable that is instantiated with the same
> name should overwrite the arguments object. Also notice the use of the
> phrase "initial value", which implies that the arguments property can
> take on another value.
but the "initial value" could have been overwritten by the
function-declarations (where it is explicitly stated, that existing
properties are overwritten). There's just no mention of already existing
properties in the parameter-list instantiation, and as I (incorrectly)
thought, that all existing JS-implementations don't overwrite the
arguments-property I was confused.
thx for the clarifications.
// florian

Michael Winter wrote:

> function testArguments() {
> var arguments = 'string';
>
> alert(arguments + ' ' + testArguments.arguments);
> }

There was no "var arguments" statement in Florian's code, but an
argument identifier "arguments". Look at this example:

function testArguments(arguments, baz) {
alert([
"1: " + arguments,
"2: " + (testArguments.arguments && testArguments.arguments[1]),
"3: " + testArguments[1]
].join("\n"));
}
testArguments("foo", "bar");

> that approach is
> deprecated as of JS1.4 and is not present in the ECMAScript standard.

Referencing the arguments array as a property of the function object
only. MSIE does not care about this. I didn't say I'd like that, I just
wanted to show that the initial arguments object is not deleted in both
major browsers.

> Why should it be? It's not necessary. [...] don't create a local
> variable (of any origin) with the same name

Didn't I say that I wouldn't ever do so?

ciao, dhgm

Dietmar Meier wrote:

> Michael Winter wrote:
>
>> function testArguments() {
>> var arguments = 'string';
>>
>> alert(arguments + ' ' + testArguments.arguments);
>> }
>
> There was no "var arguments" statement in Florian's code,

It was an example. I used variations that included all local types:
variable, function, and formal argument declarations (though the
former was a declaration/initialisation pair, as posted). In each
cases, the arguments object was overwritten in at least one browser.
As Firefox overwrote the object in every case, which browsers exhibit
what effects is immaterial from a Web scripting perspective.

> [...] both major browsers.

Which would those be?

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Florian Loitsch wrote:

[snip]

> the "initial value" could have been overwritten by the
> function-declarations (where it is explicitly stated, that existing
> properties are overwritten).

When I referred to "any local variable", I meant /any/ local;
function, variable, or formal argument. That said, as variable
declarations are not supposed to replace the value of existing locals,
the variable would also have to undergo explicit initialisation.

> There's just no mention of already existing properties in the
> parameter-list instantiation

Most likely because it's presumed that no argument will be given the
name of a known identifier, and that amongst user-defined locals,
formal parameters are instantiated first so there isn't a standard
case where there would be existing properties (with the exception of
arguments with the same name, which is covered, but that still isn't
standard).

> I (incorrectly) thought, that all existing JS-implementations don't
> overwrite the arguments-property [...]

If a property isn't noted for possessing the ReadOnly attribute, you
can assume that the value can be overwritten. The only exceptions
might be where an implementation has added the ReadOnly attribute on
its own initiative (which is acceptable for conforming
implementations, but sometimes annoying).

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.