Thq Quiz

Discussion in 'Javascript' started by Dmitry A. Soshnikov, Feb 19, 2010.

  1. If some will be interested, one more ES quiz: <URL:
    http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz>

    For regulars of this group it shouldn't be hard.

    /ds
     
    Dmitry A. Soshnikov, Feb 19, 2010
    #1
    1. Advertising

  2. Dmitry A. Soshnikov wrote:
    > If some will be interested, one more ES quiz: <URL:
    > http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz>
    >
    > For regulars of this group it shouldn't be hard.
    >


    #5 is a good one for understanding Grouping Operator and Reference.

    #6 is better. Seems Chrome gets that feature wrong.

    function testArgOutsideLength(a){
    a = 1;
    alert([arguments.length, arguments[0]]);
    }

    javascript: function testArgOutsideLength(a){ var inBefore = "0" in
    arguments; a = 1; alert([inBefore, "0" in arguments]);}
    testArgOutsideLength()

    Where chrome elerts:
    "0, 1"

    A more interesting variation, my "response question":
    alert(
    function(x, y) {
    x = 10;
    y = 20;
    return[
    ""+x,
    ""+arguments[0],
    ""+y,
    ""+arguments[1]
    ];
    }(1));

    The answer to my "response question" is below.

    There seem to be some changes in ES5 but I have not read up on those.
    The arguments object, as specified, more complex than need be.

    A fixed Spidermonkey bug: <URL:
    https://bugzilla.mozilla.org/show_bug.cgi?id=292215 > (fixed) where
    assigning to arguments[n] where `n` was >= function.length or >= the
    number of actual arguments.

    In Safari 2, IIRC, (and probably Konqueror), there is also a bug where
    passed args are not synced with the arguments object, so assigning to
    the arg does not update the arguments object.

    A similar bug exists in FF and IE where the args and the arguments
    object syncing does not persist after the function returns:
    <URL: http://bugs.ecmascript.org/ticket/447 >

    Answer to my "response question" is explained by Ecma-262, r3 s 10.1.8
    "Arguments Object":

    | A property is created with name length and property attributes {
    | DontEnum }. The initial value of this property is the number of actual
    | parameter values supplied by the caller.
    |

    alert(
    function(x, y) {
    // arguments.length = 1.
    }(1));

    | 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 { DontEnum }.

    alert(
    function(x, y) {
    // arguments.length = 1.
    // arguments["0"] {DontEnum}
    x = 10;
    y = 20;
    }(1));

    | The initial value of this property is the
    | value of the corresponding actual parameter supplied by the caller.

    Updating the code comments to reflect that:

    alert(
    function(x, y) {
    // arguments.length = 2.
    // arguments["0"] = 1 {DontEnum}
    x = 10;
    y = 20;
    }(1));

    | 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.

    At this point, `y` would share its value with arguments[1], but
    arguments does not have "1" property. Since no "1" property exists on
    the arguments object, the property `y` has nothing to share its value
    with. To handle this situation, Chrome *creates* a property of the
    arguments object to share value with.

    The result is arguments gets a "1" property and arguments.length is 1.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Feb 20, 2010
    #2
    1. Advertising

  3. kangax wrote:
    > On 2/20/10 4:09 AM, Garrett Smith wrote:
    >

    [...]

    >>
    >> alert(
    >> function(x, y) {
    >> // arguments.length = 1.


    Right.

    >> }(1));
    >>
    >> | 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 { DontEnum }.
    >>
    >> alert(
    >> function(x, y) {
    >> // arguments.length = 1.


    Still right.

    >> // arguments["0"] {DontEnum}
    >> x = 10;
    >> y = 20;
    >> }(1));
    >>
    >> | The initial value of this property is the
    >> | value of the corresponding actual parameter supplied by the caller.
    >>
    >> Updating the code comments to reflect that:
    >>
    >> alert(
    >> function(x, y) {
    >> // arguments.length = 2.

    > ^^^


    What happened to `1`?

    > I don't see why arguments.length should change from 1 to 2 here. Typo?


    `1` is correct because there was one actual argument passed in that
    example.

    It's not like copy'n'paste is all that hard. Apparently I copied right
    the first time, but not the second. I should take my own advice about
    late-night messages. Plus I need more sleep anyway.

    [...]

    I did file a bug on it, too, using another example.
    http://code.google.com/p/chromium/issues/detail?id=36350

    >
    > These kind of things should really be caught by a conformance test suite
    > like Sputniktests [1]. The fact that they're not (I'm not sure, haven't
    > checked) shows that test suite has gaps and still needs work.
    >


    I think that bug reflects the problems with too much complexity around
    `arguments` feature. Even in a very recent build of a major
    implementation has an issue. The other issues I listed support my
    argument that the complexity around `arguments` causes implementation
    problems.

    In an es-discuss thread about fixing `arguments` Brendan made a remark
    about it being something like "polishing a turd," which I thought both
    funny and appropriate.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Feb 21, 2010
    #3
  4. On Feb 20, 12:09 pm, Garrett Smith <> wrote:

    >
    > #6 is better. Seems Chrome gets that feature wrong.
    >


    Yeah, that's right, Chrome still cannot get it right. Regarding to
    ECMA-262-3, 10.1.8:

    |A property is created with name length and property attributes
    { DontEnum }.
    |The initial value of this property is the number of *actual parameter
    values supplied by the caller*.

    function foo(x) {
    x = 42;
    console.log(arguments.length); // 0
    console.log(arguments[0]); // undefined
    return arguments[0];
    }

    // number of actual
    // parameter values is 0
    f(); // undefined

    /ds
     
    Dmitry A. Soshnikov, Feb 21, 2010
    #4
  5. Richard Cornford wrote:
    > kangax" wrote:
    >> On 2/20/10 8:47 PM, Garrett Smith wrote:

    > <snip>
    >>> I did file a bug on it, too, using another example.
    >>> http://code.google.com/p/chromium/issues/detail?id=36350

    >>
    >> Did you mean:
    >> <http://code.google.com/p/chromium/issues/detail?id=36328> ?
    >>

    Probably got deleted as a dup.
    [..]
    >
    > It could be argued that this is not a bug. The spec's conformance
    > section explicitly allows objects to have properties in addition to
    > those specified.


    [...]

    http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz#q6

    If this is not a bug, then all of question 6's options must be
    acceptable as correct answers.

    function f(x, y) {
    x = 10;
    console.log(
    arguments[0],
    arguments[1]
    );
    }

    f();

    (a) 10, null
    (b) 10, undefined
    (c) undefined, undefined
    (d) 10, NaN
    (e) 10, 10

    It seems odd for a program to expect the `arguments` object not to have
    a "0" property at that point. The oddness of the situation may be a good
    reason the chrome bug (AISI) went on unnoticed for so long.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Feb 23, 2010
    #5
  6. On Feb 23, 1:19 am, "Richard Cornford" <>
    wrote:

    [...]

    >
    > It could be argued that this is not a bug. The spec's conformance
    > section explicitly allows objects to have properties in addition to
    > those specified. There would be a problem if the - arguments.length -
    > changed when - arguments[0] - was added to the object, but as that does
    > not happed the result is an arguments object with all the specified
    > properties having all the specified values and behaviour, and no more
    > than the additional properties that ES3 allows.
    >


    Many things in ES3 could be debatable as many things (no less than
    spec itself) are ambiguous, but that was recognized (by many
    implementations) as a bug as spec says exactly (ES3, 10.1.8):

    | ... is the number of *actual parameter
    | values supplied by the caller*

    Whether it's debatable and ambiguous - that's already another
    question.

    /ds
     
    Dmitry A. Soshnikov, Feb 23, 2010
    #6
  7. On Feb 23, 4:04 am, Garrett Smith <> wrote:

    [...]

    >
    > If this is not a bug ...
    >


    It's a bug. The question and the meaning are very ambiguous (from the
    human viewpoint), but regarding to spec (which is itself ambiguous in
    many moments) - it's a bug.

    >
    > It seems odd for a program to expect the `arguments` object not to have
    > a "0" property at that point.
    >


    Yes, it could be so. But from the other side: current spec's behavior
    is a consequence of that quantity of formal parameters - is
    <constructor>.length, and the quantity of the _actual_ parameters - is
    `arguments.length'. For what reason there should be 1 or 2, but not
    (correctly) 0? And if they would made that local variable from the
    activation object would share its name also in this case (when there's
    no any parameter passed) - it's also be ambiguous - e.g. for check
    where user *really* passed something to function (could be useful with
    overloading by parameters length).

    So abstractly this case turns out like function has no parameters at
    all, and `x' - is just a local variable:

    function foo(x, y) { x = 10 }

    foo(20, 30) => foo(x, y) { x = 10 }
    foo(40) => foo(x) { x = 10 }
    foo(50) => foo() { [var ]x = 10 }

    >
    > The oddness of the situation may be a good
    > reason the chrome bug (AISI) went on unnoticed for so long.
    >


    Maybe. They can write a suggestion to change the behavior (but not
    arguing that spec allows any other additional properties - as in this
    cases - all the spec can be doubtful, but providing alternative
    unequivocal meaning, taking into account all the existing features).
    But also can be that they just forgot to fix it according to ES3
    10.1.8.

    /ds
     
    Dmitry A. Soshnikov, Feb 23, 2010
    #7
  8. On Feb 23, 11:10 am, "Richard Cornford" <>
    wrote:
    > Garrett Smith wrote:


    [...]

    >
    > >http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz#q6

    >
    > > If this is not a bug, then all of question 6's options
    > > must be acceptable as correct answers.

    >
    > And a lot of other possible answers as well.


    Do you mean answers on other questions? For example? If you provide
    really ambiguous cases (except question #2 which is already
    discussed), I'll update the post.

    > ECMA 262 3rd Ed. says
    > that - arguments.length - should be zero, but does not make any
    > assertions about the values of integer index named properties where the
    > integer values are greater or equal to - arguments.length -.
    >


    But it says about the case when it *less* than quantity of actual
    arguments.

    >
    >
    > > function f(x, y) {
    > >   x = 10;
    > >   console.log(
    > >     arguments[0],
    > >     arguments[1]
    > >   );
    > > }

    >
    > > f();

    >
    > > (a) 10, null
    > > (b) 10, undefined
    > > (c) undefined, undefined
    > > (d) 10, NaN
    > > (e) 10, 10

    >
    > > It seems odd for a program to expect the `arguments` object
    > > not to have a "0" property at that point.

    >
    > The interpretation of the spec that says an arguments object may have
    > integer indexed properties beyond - arguments.length - has implications
    > for some styles of method overloading emulation, as you would have to
    > verify argumetns.length before making deductions from a value in -
    > arguments[n] -.
    >


    Yeah, I think this is one of the main reasons (possibility of checking
    _real_ arguments.length) of this strange behavior. And even if there's
    `x = 10' - still to have ability to check _real_ `arguments.length'
    which should be 0 and as a consequence, `arguments[0]' shouldn't
    appear. Although, yeah, the behavior is ambiguous.

    > > The oddness of the situation may be a good reason the chrome bug
    > > (AISI) went on unnoticed for so long.

    >
    > If it is a bug at all.
    >


    Yeah, by the 10.1.8 it shouldn't be, but as for ambiguous behavior -
    it could be changed and recognized as a bug (but with providing a good
    alternative for behavior).

    /ds
     
    Dmitry A. Soshnikov, Feb 23, 2010
    #8
  9. On Feb 23, 10:31 am, Dmitry A. Soshnikov wrote:
    > On Feb 23, 1:19 am, Richard Cornford wrote:
    > [...]
    >> It could be argued that this is not a bug. The spec's conformance
    >> section explicitly allows objects to have properties in addition to
    >> those specified. There would be a problem if the - arguments.length
    >> - changed when - arguments[0] - was added to the object, but as
    >> that does not happed the result is an arguments object with all
    >> the specified properties having all the specified values and
    >> behaviour, and no more than the additional properties that ES3
    >> allows.

    >
    > Many things in ES3 could be debatable as many things (no less than
    > spec itself) are ambiguous, but that was recognized (by many
    > implementations) as a bug as spec says exactly (ES3, 10.1.8):
    >
    > | ... is the number of *actual parameter
    > | values supplied by the caller*


    That is the specification for the - length - property of the
    - arguments - object, but do we have any evidence of an environment
    where the - length - property is incorrect? My quick tests of Chrome
    show the addition of an - arguments[n] - when assigning to a
    corresponding formal parameter for which no actual argument was
    passed, but that the - arguments.length - value is not altered by
    this action (and so does not become incorrect).

    The - length - property is not specified as relating to the number of
    'integer index' properties of the - arguments - object, and the only
    'integer index' properties specified are those where the integer would
    be less than - length -.

    > Whether it's debatable and ambiguous - that's already another
    > question.


    ECMA 262 3rd Ed. specifies the argument object's [[Prototype]], its
    callee, its length and "non-negative integer" properties "less than
    the value of the length property". This "bug" does not present any
    evidence of any of these specified properties having incorrect values
    or behaviours.

    The conformance section (1) starts out stating that: "A conforming
    implementation of ECMAScript must provide and support all the types,
    values, objects, properties,
    functions, and program syntax and semantics described in this
    specification.", but for an arguments object all of the properties,
    syntax and semantics appear to be correct where Chrome is concerned.

    The conformance section also says: "A conforming implementation of
    ECMAScript is permitted to provide additional types, values, objects,
    properties, and functions beyond those described in this
    specification.", and what we have is evidence of properties of an
    arguments "beyond" (literally in this case) to those specified.

    You can argue that the situation as it manifests itself in Chrome is a
    bad idea, and observe that others have made different (even better)
    decisions, but I cannot see how this violates the specification in any
    way. Therefore it is not an implementation bug.

    Richard.
     
    Richard Cornford, Feb 23, 2010
    #9
  10. On Feb 23, 2:24 pm, Richard Cornford <>
    wrote:
    > On Feb 23, 10:31 am, Dmitry A. Soshnikov wrote:
    >
    >
    >
    > > On Feb 23, 1:19 am, Richard Cornford wrote:
    > > [...]
    > >> It could be argued that this is not a bug. The spec's conformance
    > >> section explicitly allows objects to have properties in addition to
    > >> those specified. There would be a problem if the - arguments.length
    > >> - changed when - arguments[0] - was added to the object, but as
    > >> that does not happed the result is an arguments object with all
    > >> the specified properties having all the specified values and
    > >> behaviour, and no more than the additional properties that ES3
    > >> allows.

    >
    > > Many things in ES3 could be debatable as many things (no less than
    > > spec itself) are ambiguous, but that was recognized (by many
    > > implementations) as a bug as spec says exactly (ES3, 10.1.8):

    >
    > > | ... is the number of *actual parameter
    > > | values supplied by the caller*

    >


    > That is the specification for the - length - property of the
    > - arguments - object


    Not only, the spec says about the concrete and exact case *when
    arguments properties share their values with corresponding variables
    of the activation object*. And this case is related to
    `arguments.length'. Sure, arguments can be augment with new properties
    on runtime context phase (which executes after entering the context
    phase at which `arguments' (and all the other stuff) is created).

    > but do we have any evidence of an environment
    > where the - length - property is incorrect?


    No, with `arguments.length' everything's OK - in all implementations -
    it shouldn't be changed as `arguments' is not an array, thus has no
    overloaded [[Put]] for that. So it should be always 0 in this case.

    > My quick tests of Chrome
    > show the addition of an - arguments[n] - when assigning to a
    > corresponding formal parameter for which no actual argument was
    > passed, but that the - arguments.length - value is not altered by
    > this action (and so does not become incorrect).
    >


    With `.length' that's OK, as mentioned above, but Chrome makes error
    with *fact of sharing* the value of local variable, and the case when
    this fact should be true is described in 10.1.8 and depends on actual
    `arguments.length' analyzed on entering the context. The conformant
    implementation (as I see it) is:

    function foo(x) {
    x = 10;
    alert(arguments[0]); // should undefined
    arguments[0] = 100;
    alert([
    arguments[0], // should be 100
    x, // should be 10, as doesn't share
    arguments.length // should be 0, as [[Get]] isn't overloaded
    ]);
    }

    foo();

    And only in Chrome we have "100, 100, 100, 0", meanwhile in other:
    "undefined, 100, 10, 0".

    > The - length - property is not specified as relating to the number of
    > 'integer index' properties of the - arguments - object, and the only
    > 'integer index' properties specified are those where the integer would
    > be less than - length -.
    >


    The main goal of the last bullet of 10.1.8 even is not in
    `length' (although, in `length' also), but in specifying *exact
    behavior and the case* when implementation should share `arguments'
    index-properties values and local variables of the activation object.

    >
    > You can argue that the situation as it manifests itself in Chrome is a
    > bad idea, and observe that others have made different (even better)
    > decisions
    >


    Yeah, some (all?) other implementations recognize it as bug. For
    example, I found in code of SpiderMonkey comment related to bug
    mentioned above by Garrett where implementors also agree that the
    behavior of 10.1.8 should be treated so:

    <URL: http://mxr.mozilla.org/mozilla/source/js/src/jsfun.c#210>

    > but I cannot see how this violates the specification in any
    > way. Therefore it is not an implementation bug.
    >


    As I mentioned, it's in the last bullet of the 10.1.8, where the exact
    case when `arguments' and local variables should be shared is
    described.

    /ds
     
    Dmitry A. Soshnikov, Feb 23, 2010
    #10
  11. On Feb 23, 7:15 pm, Dmitry A. Soshnikov wrote:
    > On Feb 23, 2:24 pm, Richard Cornford wrote:
    >> On Feb 23, 10:31 am, Dmitry A. Soshnikov wrote:
    >>> On Feb 23, 1:19 am, Richard Cornford wrote:
    >>> [...]
    >>>> It could be argued that this is not a bug. The spec's conformance
    >>>> section explicitly allows objects to have properties in addition
    >>>> to those specified. There would be a problem if the -
    >>>> arguments.length - changed when - arguments[0] - was added to
    >>>> the object, but as that does not happed the result is an
    >>>> arguments object with all the specified properties having all
    >>>> the specified values and behaviour, and no more than the
    >>>> additional properties that ES3 allows.

    >
    >>> Many things in ES3 could be debatable as many things (no less
    >>> than spec itself) are ambiguous, but that was recognized (by
    >>> many implementations) as a bug as spec says exactly (ES3,
    >>> 10.1.8):

    >
    >>> | ... is the number of *actual parameter
    >>> | values supplied by the caller*

    >
    >> That is the specification for the - length - property of the
    >> - arguments - object

    >
    > Not only,


    So which other value represents "the number of *actual parameter
    values supplied by" the caller*"?

    > the spec says about the concrete and exact case *when
    > arguments properties share their values with corresponding
    > variables of the activation object*.


    Only "In the cases when arg is less then the number of formal
    parameters for the function" and after constraining arg to all "non-
    negative integers" "less then the value of the length property".

    > And this case is related to `arguments.length'. Sure, arguments
    > can be augment with new properties on runtime context phase
    > (which executes after entering the context phase at which
    > `arguments' (and all the other stuff) is created).


    I don't understand that last sentence.

    >> but do we have any evidence of an environment
    >> where the - length - property is incorrect?

    >
    > No, with `arguments.length' everything's OK - in all
    > implementations - it shouldn't be changed as `arguments' is
    > not an array, thus has no overloaded [[Put]] for that. So
    > it should be always 0 in this case.
    >
    >> My quick tests of Chrome
    >> show the addition of an - arguments[n] - when assigning to a
    >> corresponding formal parameter for which no actual argument was
    >> passed, but that the - arguments.length - value is not altered
    >> by this action (and so does not become incorrect).

    >
    > With `.length' that's OK, as mentioned above, but Chrome makes
    > error with *fact of sharing* the value of local variable, and
    > the case when this fact should be true is described in 10.1.8
    > and depends on actual `arguments.length' analyzed on entering
    > the context. The conformant implementation (as I see it) is:
    >
    > function foo(x) {
    > x = 10;
    > alert(arguments[0]); // should undefined


    Based on what? In this case - arguments.length - is zero, and so there
    is no specified value or behaviour for an - arguments[0] - property in
    this case.

    > arguments[0] = 100;
    > alert([
    > arguments[0], // should be 100


    Yes it should, as the - arguments[0] - property has just been assigned
    that value.

    > x, // should be 10, as doesn't share


    That is much harder to justify. While successful assignment would not
    normally be expected to have side effects on the values of the
    properties of other objects I don't see anything that forbids this.

    > arguments.length // should be 0, as [[Get]] isn't overloaded
    > ]);
    >
    > }
    >
    > foo();
    >
    > And only in Chrome we have "100, 100, 100, 0", meanwhile in
    > other: "undefined, 100, 10, 0".


    But as there is no 'correct' outcome to be derived from the
    specification it is not possible to declare either to be wrong.
    Interactions with 'integer index' properties of the - arguments -
    object that are equal to or greater than - arguments.length - are not
    specified at all.

    >> The - length - property is not specified as relating to the
    >> number of 'integer index' properties of the - arguments -
    >> object, and the only 'integer index' properties specified
    >> are those where the integer would be less than - length -.

    >
    > The main goal of the last bullet of 10.1.8 even is not in
    > `length' (although, in `length' also), but in specifying
    > *exact behavior and the case* when implementation should
    > share `arguments' index-properties values and local
    > variables of the activation object.


    Whatever the motivation of the section, the wording of the section
    specifies exact behaviour for a length property and all non-negative
    'integer index' properties that are less than the length value. It
    says nothing about the existence (or non-existence), value or
    behaviour of 'integer index' properties that are equal to or greater
    than length; there are no constraints placed on such properties in
    that section.

    It would be possible to argue that whatever is not specified is
    therefore forbidden, but that position would instantly collapse at the
    third paragraph of the conformance section; you cannot forbid all that
    is not specified at the same time as allowing "additional types,
    objects, properties and functions beyond those described in this
    specification".

    Section 10.1.8 specifies the values and behaviour of non-negative
    integer index properties of the - arguments - object that are less
    than the - arguments.length - value, and it stops there. Beyond that
    the language's conformance rules allow anything that does not
    contradict what is specified.

    >> You can argue that the situation as it manifests itself
    >> in Chrome is a bad idea, and observe that others have
    >> made different (even better) decisions

    >
    > Yeah, some (all?) other implementations recognize it as bug.


    You cannot assume that. It is entirely possible that where it is
    recognised at all the behaviour chosen was chosen because it was seen
    as sensible.

    > For example, I found in code of SpiderMonkey comment related
    > to bug mentioned above by Garrett where implementors also
    > agree that the behavior of 10.1.8 should be treated so:
    >
    > <URL:http://mxr.mozilla.org/mozilla/source/js/src/jsfun.c#210>


    Is that an appeal to authority? Individuals, including those working
    on script engine software, are capable of misinterpreting the
    specification, reading more in that is there, or even just expressing
    themselves imprecisely/poorly.

    (just as I am, which is what makes having this discussion in public
    worthwhile. Burred in the spec somewhere they may be something that
    would make this Chrome feature an ECMAScript implementation bug. It is
    not in section 10.1.8, but that does not mean that nobody here will be
    able to point something out).

    >> but I cannot see how this violates the specification in any
    >> way. Therefore it is not an implementation bug.

    >
    > As I mentioned, it's in the last bullet of the 10.1.8, where
    > the exact case when `arguments' and local variables should be
    > shared is described.


    If it is there, by all means cite the text that imposes constraints on
    the existance, values or behaviour of 'integer index' properties of
    the - arguments - object that are equal to or greater than -
    arguments.length -. I don't see it.

    Richard.
     
    Richard Cornford, Feb 24, 2010
    #11
  12. On Feb 24, 2:43 pm, Richard Cornford <>
    wrote:

    [...]

    >
    > >> That is the specification for the - length - property of the
    > >> - arguments - object

    >
    > > Not only,

    >
    > So which other value represents "the number of *actual parameter
    > values supplied by" the caller*"?
    >


    Seems you didn't understand correctly, by "not only" I meant that
    10.1.8 says not only the length property but also about the exact case
    when properties of `arguments' object and and corresponding formal
    parameters should be shared.

    > > the spec says about the concrete and exact case *when
    > > arguments properties share their values with corresponding
    > > variables of the activation object*.

    >
    > Only "In the cases when arg is less then the number of formal
    > parameters for the function" and after constraining arg to all "non-
    > negative integers" "less then the value of the length property".
    >


    Do I understand correctly that you argue about that if
    arguments.length == 0, than implementation can share corresponding
    formal *first* parameter as index-property of the `arguments[0]' is
    *equal to* 0, but not less as told in spec? If so, sorry, this is just
    a _too formal_ attempt to think out "how could it be if ...". And
    doesn't it mean that for `arguments[1]' shouldn't share the
    corresponding formal parameter (1 < 0, where 0 - is the
    `arguments.length')? But it does. As it does (wrong) for
    `arguments[0]'.

    Your current arguing reminds some case in court when everybody
    understands that it is wrong, but because of _some formal ambiguity_
    (a "formal hole in the law") is will be justified. Sorry, no, it
    won't.

    > > And this case is related to `arguments.length'. Sure, arguments
    > > can be augment with new properties on runtime context phase
    > > (which executes after entering the context phase at which
    > > `arguments' (and all the other stuff) is created).

    >
    > I don't understand that last sentence.
    >


    Doesn't matter, I meant that it's possible to add new properties to
    `arguments' object (but they shouldn't affect the `.length' property,
    what I said in another sentence).


    > > function foo(x) {
    > >   x = 10;
    > >   alert(arguments[0]); // should undefined

    >
    > Based on what? In this case - arguments.length - is zero, and so there
    > is no specified value or behaviour for an - arguments[0] - property in
    > this case.
    >


    I said above - it's just an attempt to be hooked for ambiguity of the
    specification. If Chrome is correct by your words, than it shouldn't
    share `y' (let's assume it's the second parameter) and `arguments[1]'
    in case when no parameters are passed. But Chrome shares them in all
    that cases, which is wrong. Referencing to conformance section also
    isn't fit here - because implementation can create any other
    properties (as many as it want), but shouldn't disturb the description
    of concrete algorithm (10.1.8 in this case; see for `arguments[1]'
    then if you still want to argue about 0 == 0, but not less than).

    > >   arguments[0] = 100;
    > >   alert([
    > >     arguments[0], // should be 100

    >
    > Yes it should, as the - arguments[0] - property has just been assigned
    > that value.
    >
    > >     x, // should be 10, as doesn't share

    >
    > That is much harder to justify. While successful assignment would not
    > normally be expected to have side effects on the values of the
    > properties of other objects I don't see anything that forbids this.
    >


    Yeah, that's true (any side effect could be, which specification
    doesn't forbid), but this exact case is forbidden by 10.1.8 (again,
    you can choose to analyze arguments[1], y, and the case when no
    parameters passed to (x, y) function).

    > >     arguments.length // should be 0, as [[Get]] isn't overloaded
    > >   ]);

    >
    > > }

    >
    > > foo();

    >
    > > And only in Chrome we have "100, 100, 100, 0", meanwhile in
    > > other: "undefined, 100, 10, 0".

    >
    > But as there is no 'correct' outcome to be derived from the
    > specification it is not possible to declare either to be wrong.
    > Interactions with 'integer index' properties of the - arguments -
    > object that are equal to or greater than - arguments.length - are not
    > specified at all.
    >


    Mentioned above, it seems like formal catching the hole in ambiguous
    specification description, but I can't find useful application of it.
    Then use arguments[1] and y, when .length will be 0, and Chrome will
    try to share 1 which is grater than 0. Do I understand correctly that
    for you statements "1 is grater than 0" (with which you're trying to
    argue) and "0 is less than 1" are not equivalent for this case?

    > >> The - length - property is not specified as relating to the
    > >> number of 'integer index' properties of the - arguments -
    > >> object, and the only 'integer index' properties specified
    > >> are those where the integer would be less than - length -.

    >
    > > The main goal of the last bullet of 10.1.8 even is not in
    > > `length' (although, in `length' also), but in specifying
    > > *exact behavior and the case* when implementation should
    > > share `arguments' index-properties values and local
    > > variables of the activation object.

    >
    > Whatever the motivation of the section, the wording of the section
    > specifies exact behaviour for a length property and all non-negative
    > 'integer index' properties that are less than the length value. It
    > says nothing about the existence (or non-existence), value or
    > behaviour of 'integer index' properties that are equal to or greater
    > than length; there are no constraints placed on such properties in
    > that section.
    >


    Yeah, I mentioned it above.

    > It would be possible to argue that whatever is not specified is
    > therefore forbidden, but that position would instantly collapse at the
    > third paragraph of the conformance section; you cannot forbid all that
    > is not specified at the same time as allowing "additional types,
    > objects, properties and functions beyond those described in this
    > specification".
    >
    > Section 10.1.8 specifies the values and behaviour of non-negative
    > integer index properties of the - arguments - object that are less
    > than the - arguments.length - value, and it stops there. Beyond that
    > the language's conformance rules allow anything that does not
    > contradict what is specified.
    >
    > >> You can argue that the situation as it manifests itself
    > >> in Chrome is a bad idea, and observe that others have
    > >> made different (even better) decisions

    >
    > > Yeah, some (all?) other implementations recognize it as bug.

    >
    > You cannot assume that. It is entirely possible that where it is
    > recognised at all the behaviour chosen was chosen because it was seen
    > as sensible.
    >


    On implementation level this should be so. Some ambiguous cases should
    be treated as logical as possible, but without finding "law holes" and
    choosing this way to implement (and moreover, argue after than
    referencing on it).

    > > For example, I found in code of SpiderMonkey comment related
    > > to bug mentioned above by Garrett where implementors also
    > > agree that the behavior of 10.1.8 should be treated so:

    >
    > > <URL:http://mxr.mozilla.org/mozilla/source/js/src/jsfun.c#210>

    >
    > Is that an appeal to authority?


    Strange to hear that. Never. Seems, you confuse me to someone. But if
    you insist: this is just _an example_.

    > Individuals, including those working
    > on script engine software, are capable of misinterpreting the
    > specification, reading more in that is there, or even just expressing
    > themselves imprecisely/poorly.
    >
    > (just as I am, which is what makes having this discussion in public
    > worthwhile. Burred in the spec somewhere they may be something that
    > would make this Chrome feature an ECMAScript implementation bug. It is
    > not in section 10.1.8, but that does not mean that nobody here will be
    > able to point something out).
    >


    Yes, it could be so, but I think this case is clear although is very
    ambiguous and can be appellate with references which you mention. The
    other question - what is the big deal of that too formal appellations
    for the implementation level? I don't see a big. Although, I clearly
    understand your position.

    /ds
     
    Dmitry A. Soshnikov, Feb 24, 2010
    #12
  13. On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote:
    > On Feb 24, 2:43 pm, Richard Cornford wrote:
    > [...]
    >>>> That is the specification for the - length - property of the
    >>>> - arguments - object

    >
    >>> Not only,

    >
    >> So which other value represents "the number of *actual parameter
    >> values supplied by" the caller*"?

    >
    > Seems you didn't understand correctly, by "not only" I meant that
    > 10.1.8 says not only the length property but also about the exact
    > case when properties of `arguments' object and and corresponding
    > formal parameters should be shared.


    No, section 10.1.8 specifies a minimum set of properties of the -
    arguments - object that will share values with formal parameters. It
    does not constrain the values or behaviours of any - arguemnts -
    object 'integer index' properties that are not in that set.

    >>> the spec says about the concrete and exact case *when
    >>> arguments properties share their values with corresponding
    >>> variables of the activation object*.

    >
    >> Only "In the cases when arg is less then the number of formal
    >> parameters for the function" and after constraining arg to all
    >> "non- negative integers" "less then the value of the length
    >> property".

    >
    > Do I understand correctly that you argue about that if
    > arguments.length == 0, than implementation can share corresponding
    > formal *first* parameter as index-property of the `arguments[0]'
    > is *equal to* 0, but not less as told in spec?


    I am pointing out that there are boundaries to what is being specified
    in 10.1.8, and that as the behaviour that is being subject to
    criticism is outside of those boundaries section 10.1.8 does not apply
    to it.

    > If so, sorry, this
    > is just a _too formal_ attempt to think out "how could it be if
    > ...". And doesn't it mean that for `arguments[1]' shouldn't share
    > the corresponding formal parameter (1 < 0, where 0 - is the
    > `arguments.length')? But it does. As it does (wrong) for
    > `arguments[0]'.


    I don't understand that sentence.

    > Your current arguing reminds some case in court when everybody
    > understands that it is wrong, but because of _some formal
    > ambiguity_ (a "formal hole in the law") is will be justified.
    > Sorry, no, it won't.


    Yes, of course. But the accusation being made is taking the form of
    accusing Chrome of violating ECMA 262 3rd Ed; that the behaviour
    exhibited represents an ECMAScript implementation bug. This accusation
    is false, as the behaviour exhibited is fully accommodated by the
    specification.

    Now if someone wanted to accuse Chrome of doing something that was
    stupid, not a good idea, of no practical use or help to anyone, etc.
    then that is all fine (and probably true), but let us not call it an
    ECMAScript implementation bug unless it is an ECMAScript
    implementation bug.

    >>> And this case is related to `arguments.length'. Sure, arguments
    >>> can be augment with new properties on runtime context phase
    >>> (which executes after entering the context phase at which
    >>> `arguments' (and all the other stuff) is created).

    >
    >> I don't understand that last sentence.

    >
    > Doesn't matter, I meant that it's possible to add new properties
    > to `arguments' object (but they shouldn't affect the `.length'
    > property, what I said in another sentence).
    >
    >>> function foo(x) {
    >>> x = 10;
    >>> alert(arguments[0]); // should undefined

    >
    >> Based on what? In this case - arguments.length - is zero, and
    >> so there is no specified value or behaviour for an - arguments[0]
    >> - property in this case.

    >
    > I said above - it's just an attempt to be hooked for ambiguity
    > of the specification.


    There is no ambiguity; the specification does not define anything
    about an - arguments[0] - property in this case, but does allow for
    properties and behaviour beyond what it does specify.

    > If Chrome is correct by your words,


    My words aren't important; Chrome is 'correct' by specification (in
    the sense that what it is doing is not incorrect by the
    specification).

    > than it shouldn't share `y' (let's assume it's the second
    > parameter) and `arguments[1]' in case when no parameters
    > are passed.


    Why? If the existence, value and behaviour of - arguments[0] - is
    beyond what is specified then the same will apply to - arguments[1] -,
    etc.

    > But Chrome shares them in all that cases, which is wrong.


    But only wrong by opinion, not wrong according to the specification.

    > Referencing to conformance section also isn't fit here -
    > because implementation can create any other properties
    > (as many as it want), but shouldn't disturb the description
    > of concrete algorithm (10.1.8


    The algorithm is bound by zero and - < arguments.length -. 'integer
    index' properties outside of that range are not specified, and so they
    cannot "disrupt" the algorithm.

    > in this case; see for `arguments[1]' then if you still want to
    > argue about 0 == 0, but not less than).
    >
    >>> arguments[0] = 100;
    >>> alert([
    >>> arguments[0], // should be 100

    >
    >> Yes it should, as the - arguments[0] - property has just been
    >> assigned that value.

    >
    >>> x, // should be 10, as doesn't share

    >
    >> That is much harder to justify. While successful assignment
    >> would not
    >> normally be expected to have side effects on the values of the
    >> properties of other objects I don't see anything that forbids this.

    >
    > Yeah, that's true (any side effect could be, which specification
    > doesn't forbid), but this exact case is forbidden by 10.1.8


    I don't see any text in 10.1.8 that does forbid it. I see text that
    states what values and properties can be expected of non-negative
    'inter index' properties that are less then - arguments.length -, but
    that is where it stops.

    > (again,
    > you can choose to analyze arguments[1], y, and the case when no
    > parameters passed to (x, y) function).
    >
    >>> arguments.length // should be 0, as [[Get]] isn't overloaded
    >>> ]);

    >
    >>> }

    >
    >>> foo();

    >
    >>> And only in Chrome we have "100, 100, 100, 0", meanwhile in
    >>> other: "undefined, 100, 10, 0".

    >
    >> But as there is no 'correct' outcome to be derived from the
    >> specification it is not possible to declare either to be wrong.
    >> Interactions with 'integer index' properties of the - arguments -
    >> object that are equal to or greater than - arguments.length - are not
    >> specified at all.

    >
    > Mentioned above, it seems like formal catching the hole in ambiguous
    > specification description,


    There is still no ambiguity; the specification specifies what it
    specifies, and beyond that there is the conformance section.

    > but I can't find useful application of it.
    > Then use arguments[1] and y, when .length will be 0, and Chrome
    > will try to share 1 which is grater than 0. Do I understand
    > correctly that for you statements "1 is grater than 0" (with
    > which you're trying to argue) and "0 is less than 1" are not
    > equivalent for this case?


    Less than - arguemnts.length - is what ECMA 262 specifies, and greater
    than or equal is left unspecified.

    >>>> The - length - property is not specified as relating to the
    >>>> number of 'integer index' properties of the - arguments -
    >>>> object, and the only 'integer index' properties specified
    >>>> are those where the integer would be less than - length -.

    >
    >>> The main goal of the last bullet of 10.1.8 even is not in
    >>> `length' (although, in `length' also), but in specifying
    >>> *exact behavior and the case* when implementation should
    >>> share `arguments' index-properties values and local
    >>> variables of the activation object.

    >
    >> Whatever the motivation of the section, the wording of the section
    >> specifies exact behaviour for a length property and all non-negative
    >> 'integer index' properties that are less than the length value. It
    >> says nothing about the existence (or non-existence), value or
    >> behaviour of 'integer index' properties that are equal to or greater
    >> than length; there are no constraints placed on such properties in
    >> that section.

    >
    > Yeah, I mentioned it above.


    Mentioned that there are no constraints on the existence, values or
    behaviour of 'integer index' properties that are equal to or greater
    than length?

    <snip>
    >> (just as I am, which is what makes having this discussion in public
    >> worthwhile. Burred in the spec somewhere they may be something that
    >> would make this Chrome feature an ECMAScript implementation bug.
    >> It is not in section 10.1.8, but that does not mean that nobody
    >> here will be able to point something out).

    >
    > Yes, it could be so, but I think this case is clear although is very
    > ambiguous and can be appellate with references which you mention. The
    > other question - what is the big deal of that too formal appellations
    > for the implementation level? I don't see a big.


    I don't understand that.

    > Although, I clearly understand your position.


    OK, so is what Chrome is doing an ECMAScript implementation bug or
    not?

    Richard.
     
    Richard Cornford, Feb 24, 2010
    #13
  14. On Feb 24, 5:09 pm, Richard Cornford <>
    wrote:

    [...]

    >
    > > than it shouldn't share `y' (let's assume it's the second
    > > parameter) and `arguments[1]' in case when no parameters
    > > are passed.

    >
    > Why? If the existence, value and behaviour of - arguments[0] - is
    > beyond what is specified then the same will apply to - arguments[1] -,
    > etc.
    >


    Although, I won't touch the case when 0 == 0, so it's allowed, as I
    said that this is just a formal playing on words, but is not about
    correct understanding, I ask:

    function foo(x, y) {
    y = 10;
    alert(arguments[1]);
    }

    foo();

    So, what we have:

    - `arguments.length' == 0, right?

    - 0 is less 1, right?
    - 1 is greater than 0, right?
    - 1 is *not* less than 0, right? - this is for you 10.1.8

    If the last point is correct, why does Chrome share y and [1]? As said
    absolutely clear: "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".

    Here `arg' (1) is not less than the number of formal parameters (0),
    so Chrome is wrong, right?

    If you'll answer "no", do I understand that for you "1 is greater than
    0" is not the same as "0 is less than 1"? If so, I should stop on this
    point, as this is just the play on words (which is not so useful,
    don't you think so?).

    >
    > > Although, I clearly understand your position.

    >
    > OK, so is what Chrome is doing an ECMAScript implementation bug or
    > not?
    >


    Sure not ;) Current Chrome's implementation has a bug regarding to
    10.1.8 regardless _formal_ catches and references to conformance
    section.

    By the way, what the reason of your argue?

    /ds
     
    Dmitry A. Soshnikov, Feb 24, 2010
    #14
  15. On Feb 24, 5:57 pm, "Dmitry A. Soshnikov" <>
    wrote:

    >
    > Sure not ;) Current Chrome's implementation has a bug regarding to
    > 10.1.8 regardless _formal_ catches and references to conformance
    >


    Typo: "Sure not"* is "Sure yes, Chrome has bug" as follows from other
    part of the following statement.

    /ds
     
    Dmitry A. Soshnikov, Feb 24, 2010
    #15
  16. On Feb 24, 2:57 pm, Dmitry A. Soshnikov wrote:
    > On Feb 24, 5:09 pm, Richard Cornford wrote:
    > [...]
    >>> than it shouldn't share `y' (let's assume it's the second
    >>> parameter) and `arguments[1]' in case when no parameters
    >>> are passed.

    >
    >> Why? If the existence, value and behaviour of - arguments[0]
    >> - is beyond what is specified then the same will apply to
    >> - arguments[1] -, etc.

    >
    > Although, I won't touch the case when 0 == 0, so it's
    > allowed, as I said that this is just a formal playing on
    > words, but is not about correct understanding, I ask:
    >
    > function foo(x, y) {
    > y = 10;
    > alert(arguments[1]);
    >
    > }
    >
    > foo();
    >
    > So, what we have:
    >
    > - `arguments.length' == 0, right?
    >
    > - 0 is less 1, right?


    Less than ..., but yes.

    > - 1 is greater than 0, right?
    > - 1 is *not* less than 0, right? - this is for you 10.1.8
    >
    > If the last point is correct, why does Chrome share y and [1]?
    > As said absolutely clear: "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 only occurs after 'arg' has been defined as: "For each non-
    negative integer, arg, less than the value of the length
    property, ...". If 'arg' is a non-negative integer less than the value
    of the length, and the length is zero, then there are no value that
    are 'arg', and if there are no values that are 'arg' then there are no
    cases "when arg is less than the number of formal parameters for the
    Function object". In that case no 'integer index' properties of the
    arguments object are defined by the specification, and so any that do
    exist must exist under the provisions of the conformance section and
    may have any value or behaviour that they want.

    > Here `arg' (1) is not less than the number of formal parameters (0),


    There is no 'arg' that has the value 1 when - arguments.length - is
    zero, as then there are no values that satisfy "non-negative integer,
    arg, less than the value of the length property".

    > so Chrome is wrong, right?


    Not according to the specification.

    > If you'll answer "no", do I understand that for you "1 is greater than
    > 0" is not the same as "0 is less than 1"?


    I am saying that the set of non-negative integers that are less then
    zero is empty.

    > If so, I should stop on this point, as this is just the play on
    > words (which is not so useful, don't you think so?).


    A play on words is not useful, but understanding the applicable
    specification for the language you are using is.

    >>> Although, I clearly understand your position.

    >
    >> OK, so is what Chrome is doing an ECMAScript implementation bug or
    >> not?

    >
    > Sure not ;) Current Chrome's implementation has a bug regarding to
    > 10.1.8 regardless _formal_ catches and references to conformance
    > section.


    (Taking into account your correction of the above) I still see nothing
    in that section that applies to 'integer index' properties of an -
    arguments - object that are greater than or equal to -
    arguments.length -.

    > By the way, what the reason of your argue?


    You mean beyond demonstrating that when I said that this was
    "arguable" I was telling the truth?

    When people use the specification to justify their positions I prefer
    to see that the specification does justify those positions. Mere
    opinions should be exposed as such, and justified (or not) on other
    grounds.

    Richard.
     
    Richard Cornford, Feb 24, 2010
    #16
  17. Richard Cornford wrote:
    > On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote:
    >> On Feb 24, 2:43 pm, Richard Cornford wrote:

    [...]

    >
    >> Your current arguing reminds some case in court when everybody
    >> understands that it is wrong, but because of _some formal
    >> ambiguity_ (a "formal hole in the law") is will be justified.
    >> Sorry, no, it won't.

    >
    > Yes, of course. But the accusation being made is taking the form of
    > accusing Chrome of violating ECMA 262 3rd Ed; that the behaviour
    > exhibited represents an ECMAScript implementation bug. This accusation
    > is false, as the behaviour exhibited is fully accommodated by the
    > specification.
    >


    Chrome has an interpretation of the spec that is different from what is
    specified in Ecma 262 r3.

    What Chrome does is not explicitly mentioned and so is not fully
    accommodated. OTOH, Chrome's behavior is not explicitly forbidden,
    either. It is not correct to expect that a browser won't do that.

    > Now if someone wanted to accuse Chrome of doing something that was
    > stupid, not a good idea, of no practical use or help to anyone, etc.
    > then that is all fine (and probably true), but let us not call it an
    > ECMAScript implementation bug unless it is an ECMAScript
    > implementation bug.
    >


    OK.

    >>>> And this case is related to `arguments.length'. Sure, arguments
    >>>> can be augment with new properties on runtime context phase
    >>>> (which executes after entering the context phase at which
    >>>> `arguments' (and all the other stuff) is created).
    >>> I don't understand that last sentence.

    >> Doesn't matter, I meant that it's possible to add new properties
    >> to `arguments' object (but they shouldn't affect the `.length'
    >> property, what I said in another sentence).
    >>
    >>>> function foo(x) {
    >>>> x = 10;
    >>>> alert(arguments[0]); // should undefined
    >>> Based on what? In this case - arguments.length - is zero, and
    >>> so there is no specified value or behaviour for an - arguments[0]
    >>> - property in this case.

    >> I said above - it's just an attempt to be hooked for ambiguity
    >> of the specification.

    >
    > There is no ambiguity; the specification does not define anything
    > about an - arguments[0] - property in this case, but does allow for
    > properties and behaviour beyond what it does specify.
    >


    The section on the arguments object states how and when properties are
    added. Chrome fills that in, but colors outside the lines a bit. In
    doing that, it is going against what I read as the intent of the spec,
    which is to describe precisely when properties are added to arguments
    object.

    If arguments is an Object object, then according to section 15.2.5, it
    should not have additional properties.

    | 15.2.5 Properties of Object Instances
    |
    | Object instances have no special properties beyond those inherited
    | from the Object prototype object.

    Arguments is an Object instance and so can be expected to have no
    additional properties (obviously excepting those that are explicitly
    stated).
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Feb 24, 2010
    #17
  18. Richard Cornford wrote:
    > Garrett Smith wrote:
    >> Richard Cornford wrote:
    >>> On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote:
    >>>> On Feb 24, 2:43 pm, Richard Cornford wrote:

    > <snip>
    >>>> Your current arguing reminds some case in court when
    >>>> everybody understands that it is wrong, but because
    >>>> of _some formal ambiguity_ (a "formal hole in the law")
    >>>> is will be justified. Sorry, no, it won't.
    >>>
    >>> Yes, of course. But the accusation being made is taking
    >>> the form of accusing Chrome of violating ECMA 262 3rd Ed;
    >>> that the behaviour exhibited represents an ECMAScript
    >>> implementation bug. This accusation is false, as the
    >>> behaviour exhibited is fully accommodated by the
    >>> specification.
    >>>

    >>
    >> Chrome has an interpretation of the spec that is different
    >> from what is specified in Ecma 262 r3.

    >
    > ECMA 262 specifies its own interpretation?
    >
    >> What Chrome does is not explicitly mentioned and so is
    >> not fully accommodated.

    >
    > The conformance section requires that the things that are mentioned do
    > happen. Anything that is not mentioned is not constrained or forbidden
    > by the specification. Indeed, the third paragraph of the conformance
    > section implies that anything that is not mentioned is explicitly allowed.
    >


    Ah, no. The conformance section does not imply that "anything that is
    not mentioned is explicitly allowed."

    That conformance section:

    | ..."A conforming implementation of ECMAScript is permitted to provide
    | additional types, values, objects, properties, and functions beyond
    | those described in this specification."

    I see a list of "types, values, objects, properties, and functions". Not
    "anything".

    A conforming implementation that features existing built-in Object, is
    not permitted to provide additional properties to that Object. AIQB:

    | 15.2.5 Properties of Object Instances
    | Object instances have no special properties beyond those inherited
    | from the Object prototype object.

    >> OTOH, Chrome's behavior is not explicitly forbidden, either. It is not
    >> correct to expect that a browser
    >> won't do that.
    >>
    >>> Now if someone wanted to accuse Chrome of doing something
    >>> that was stupid, not a good idea, of no practical use or
    >>> help to anyone, etc. then that is all fine (and probably
    >>> true), but let us not call it an ECMAScript implementation
    >>> bug unless it is an ECMAScript implementation bug.

    >>
    >> OK.
    >>

    > <snip>
    >>> There is no ambiguity; the specification does not define
    >>> anything about an - arguments[0] - property in this case,
    >>> but does allow for properties and behaviour beyond what
    >>> it does specify.

    >>
    >> The section on the arguments object states how and when
    >> properties are added.

    >
    > No, the specification defines a set of properties (their values and
    > behaviour) that will be added to an arguments object. Possible
    > properties beyond those specified are not covered at all.
    >
    >> Chrome fills that in,

    >
    > Chrome satisfies the requirements of the specification, in that it adds
    > the properties of the arguments object that are specified, and gives
    > then the correct values and behaviour.
    >
    >> but colors outside the lines a bit.

    >
    > Only in the sense that it does things beyond what is specified that are
    > neither required nor forbidden.
    >
    >> In doing that, it is going against what I read as the
    >> intent of the spec,

    >
    > You shouldn't try to read intent in the spec, the result will be
    > subjective and personal. Read the words in the spec.
    >



    >> which is to describe precisely when properties are added
    >> to arguments object.

    >
    > If that were the intent it would have been trivial to write the wording
    > that would make it mandatory. The absence of those words is significant.
    >
    >> If arguments is an Object object, then according to section
    >> 15.2.5, it should not have additional properties.
    >>
    >> | 15.2.5 Properties of Object Instances
    >> |
    >> | Object instances have no special properties beyond those
    >> | inherited from the Object prototype object.

    >
    > (I assume that this means that you have abandoned the idea that section
    > 10.1.8 contradicts the behavior exhibited by Chrome. i.e. your bug
    > report is incorrect in its assertion that it does.)
    >


    Either Object instances can have additional properties or they cannot.
    The section above says they cannot.

    The Arguments object is an Object instance and Object instances have no
    additional properties.

    It can be expected that arguments object has no additional properties
    except for under the specific circumstances stated in that section.

    > That section is best considered in comparison with similar section on
    > the properties of instances of other types, such as:-
    >
    > | 15.3.5 Properties of Function Instances


    The arguments object is not a function.

    [snip]

    >
    > No, an arguments object may have properties beyond those explicitly
    > specified.
    >


    Not if it is an Object instance.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Feb 25, 2010
    #18
  19. On Feb 25, 5:35 pm, Garrett Smith wrote:
    > Richard Cornford wrote:
    >> Garrett Smith wrote:
    >>> Richard Cornford wrote:
    >>>> On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote:
    >>>>> On Feb 24, 2:43 pm, Richard Cornford wrote:

    >> <snip>
    >>>>> Your current arguing reminds some case in court when
    >>>>> everybody understands that it is wrong, but because
    >>>>> of _some formal ambiguity_ (a "formal hole in the law")
    >>>>> is will be justified. Sorry, no, it won't.

    >
    >>>> Yes, of course. But the accusation being made is taking
    >>>> the form of accusing Chrome of violating ECMA 262 3rd Ed;
    >>>> that the behaviour exhibited represents an ECMAScript
    >>>> implementation bug. This accusation is false, as the
    >>>> behaviour exhibited is fully accommodated by the
    >>>> specification.

    >
    >>> Chrome has an interpretation of the spec that is different
    >>> from what is specified in Ecma 262 r3.

    >
    >> ECMA 262 specifies its own interpretation?

    >
    >>> What Chrome does is not explicitly mentioned and so is
    >>> not fully accommodated.

    >
    >> The conformance section requires that the things that are mentioned
    >> do happen. Anything that is not mentioned is not constrained or
    >> forbidden by the specification. Indeed, the third paragraph of the
    >> conformance section implies that anything that is not mentioned is
    >> explicitly allowed.

    >
    > Ah, no. The conformance section does not imply that "anything that
    > is not mentioned is explicitly allowed."
    >
    > That conformance section:
    >
    >| ..."A conforming implementation of ECMAScript is permitted to
    >| provide additional types, values, objects, properties, and
    >| functions beyond those described in this specification."
    >
    > I see a list of "types, values, objects, properties, and functions".
    > Not "anything".


    Don't forget the additional syntax allowed by the last paragraph of
    the conformance section. Once you are allowing additional types,
    values, objects, properties, functions and syntax what are you
    including in your 'anything' that is not allowed?

    > A conforming implementation that features existing built-in
    > Object,


    Such as - Object.prototype -?

    > is not permitted to provide additional properties to that
    > Object. AIQB:


    Yes they are. That is precisely what they are allowed to do, and very
    frequently do do.

    Object.prototype certainly is a built-in object, and it is pretty
    normal for it to have properties beyond those mentioned in ECMA 262.

    <snip>
    >>> If arguments is an Object object, then according to section
    >>> 15.2.5, it should not have additional properties.

    >
    >>> | 15.2.5 Properties of Object Instances
    >>> |
    >>> | Object instances have no special properties beyond those
    >>> | inherited from the Object prototype object.

    >
    >> (I assume that this means that you have abandoned the idea that
    >> section 10.1.8 contradicts the behavior exhibited by Chrome.
    >> i.e. your bug report is incorrect in its assertion that it does.)

    >
    > Either Object instances can have additional properties or they
    > cannot.


    They can.

    > The section above says they cannot.


    No, it says that, as specified in ECMA 262, they don't have any
    "special properties".

    > The Arguments object is an Object instance


    The arguments object starts off as an Object instance, it is then
    modified.

    > and Object instances have no additional properties.


    Even if I did accept that Object instances can have no properties
    beyond those listed in ECMA 262 3rd Ed., once they have been modified
    then their original state is no longer significant.

    > It can be expected that arguments object has no additional
    > properties except for under the specific circumstances stated
    > in that section.


    But it should not be expected. The stage of modifying an Object
    instance into an arguments object is precisely the sort of stage at
    which additional properties beyond those specified could be added.

    >> That section is best considered in comparison with similar section
    >> on the properties of instances of other types, such as:-

    >
    >> | 15.3.5 Properties of Function Instances

    >
    > The arguments object is not a function.


    No, but if a "Properties of ... Instances" section exists for all the
    equivalent types it should not be surprising if some of them just
    state that there is nothing to declare in such a section, while
    others, such as in the case of Function instances, list special
    properties of the instances. The absence of a list in such a context
    should not be taken as restrictive.

    If the spec wanted to say that Object instances could not have
    properties beyond those specified then it would simply have to say
    that they must not have such properties. It is the absence of such a
    restriction that means there is no restriction.

    And Function instances often have properties beyond those listed in
    section 15.3.4, such as a - name - property. This is exactly the sort
    of addition that the conformance section does allow.

    > [snip]
    >> No, an arguments object may have properties beyond those
    >> explicitly specified.

    >
    > Not if it is an Object instance.


    Yes if it is an Object instance, and yes if it was an Object instance
    that has been modified (the latter being the case here).

    Richard.
     
    Richard Cornford, Feb 25, 2010
    #19
  20. Garrett Smith wrote:

    > That conformance section:
    >
    > | ..."A conforming implementation of ECMAScript is permitted to provide
    > | additional types, values, objects, properties, and functions beyond
    > | those described in this specification."
    >
    > I see a list of "types, values, objects, properties, and functions". Not
    > "anything".


    If I am understanding correctly that the issue is that the object referred
    to by `arguments' would have additional properties, then you have clearly
    overlooked the "properties" part in that sentence. That applies to *all*
    properties of *all* objects.

    > A conforming implementation that features existing built-in Object, is
    > not permitted to provide additional properties to that Object. AIQB:
    >
    > | 15.2.5 Properties of Object Instances
    > | Object instances have no special properties beyond those inherited
    > | from the Object prototype object.


    That is not what this means, as your interpretation would directly
    contradict the Conformance section, and render several major if not all
    past and present implementations not compliant, which is a bit hard to
    believe.

    >> [...]
    >> No, an arguments object may have properties beyond those explicitly
    >> specified.

    >
    > Not if it is an Object instance.


    ISTM you are misinterpreting the Specification. That you are follows
    implicitly from the existence of `arguments.caller' in some
    implementations, which is ECMAScript-compliant behavior as well. And what
    about the properties that JavaScript adds to Object instances? Are you
    declaring JavaScript non-compliant here?


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
     
    Thomas 'PointedEars' Lahn, Feb 25, 2010
    #20
    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. Ruby Quiz

    [QUIZ] Animal Quiz (#15)

    Ruby Quiz, Jan 14, 2005, in forum: Ruby
    Replies:
    11
    Views:
    402
    James Edward Gray II
    Jan 18, 2005
  2. David Tran
    Replies:
    9
    Views:
    216
    David Tran
    Jan 21, 2005
  3. Ruby Quiz

    [QUIZ] 1-800-THE-QUIZ (#20)

    Ruby Quiz, Feb 18, 2005, in forum: Ruby
    Replies:
    15
    Views:
    341
    gabriele renzi
    Feb 24, 2005
  4. Marcelo Alvim

    [QUIZ] Newbie doubts about the quiz

    Marcelo Alvim, Aug 15, 2006, in forum: Ruby
    Replies:
    15
    Views:
    265
    Marcelo Alvim
    Aug 16, 2006
  5. Daniel Moore
    Replies:
    10
    Views:
    325
    James Gray
    Jan 31, 2009
Loading...

Share This Page