does a "parameters"-parameter overwrite the "parameters"-object?

Discussion in 'Javascript' started by Florian Loitsch, Mar 14, 2005.

  1. 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, Mar 14, 2005
    #1
    1. Advertising

  2. 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
    Dietmar Meier, Mar 14, 2005
    #2
    1. Advertising

  3. 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, Mar 15, 2005
    #3
  4. 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, Mar 15, 2005
    #4
  5. 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, Mar 15, 2005
    #5
  6. 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, Mar 15, 2005
    #6
  7. 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
    Florian Loitsch, Mar 15, 2005
    #7
  8. 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, Mar 15, 2005
    #8
  9. 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. :p 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? :D

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Mar 15, 2005
    #9
  10. 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.
    Michael Winter, Mar 15, 2005
    #10
  11. Michael Winter wrote:

    >> There was no "var arguments" statement in Florian's code,


    > It was an example. :p 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.


    Did you even look at the example in <>?

    ciao, dhgm
    Dietmar Meier, Mar 15, 2005
    #11
  12. Dietmar Meier wrote:

    [snip]

    > Did you even look at the example in <>?


    Of course. In Firefox, testArguments.arguments is undefined. Without
    the arguments formal argument, it is an object reference. What's your
    point?

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Mar 15, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VisionSet
    Replies:
    1
    Views:
    4,160
    Adam Lipscombe
    Sep 2, 2003
  2. zalla rouge
    Replies:
    0
    Views:
    461
    zalla rouge
    Sep 2, 2003
  3. John Smith

    overwrite an fstream object

    John Smith, Oct 16, 2005, in forum: C++
    Replies:
    3
    Views:
    769
    Mike Wahler
    Oct 17, 2005
  4. ukwebguy
    Replies:
    0
    Views:
    107
    ukwebguy
    Apr 13, 2006
  5. Chris
    Replies:
    1
    Views:
    85
    Mick White
    Aug 4, 2004
Loading...

Share This Page