undefined vs. undefined (was: new Array() vs [])

Discussion in 'Javascript' started by VK, Sep 9, 2006.

  1. VK

    VK Guest

    (see the post by ASM in the original thread; can be seen at
    <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/3716384d8bfa1b0b>
    as an option)

    As that is not in relevance to "new Array() vs []" question or to the
    array performance, I dared to move it to a new thread.

    Gecko takes undefined value strictly as per Book 4, Chapter 3, Song 9
    of Books of ECMA
    :)
    (Paragraph 4.3.9 of ECMAScript Language Specification, 3rd edition)
    :-|

    <quote> The undefined value is a primitive value used when a variable
    has not been assigned a value. </quote>

    As a matter complication JavaScript is the only language I know where
    one can write:
    var foo = undefined;
    which is - strictly speaking - "keep foo but assign it the value that
    foo was not assigned and never existed" which is - even more strictly
    speaking - totally meaningless.

    In case of an elision in an array initializer you *do* assign values to
    each and every array member (Mr. Cornford would say something like
    "[[Put]] method is called for each evaluation result").

    This way
    var arr = ['A',,'B']
    really means
    var arr = ['A',undefined,'B']
    with three array members explicetly assigned to the array on the
    initialization stage. And each and every *assigned* array member is
    reflected as an enumerable object property of the underlaying Object
    object. To see the difference (and the real sense of undefined value)
    try this:

    <script type="text/javascript">
    function f(arg) {
    for (var p in arg) {
    window.alert(arg[p] || 'undefined');
    }
    window.alert('loops: ' + i);
    }

    function demo() {
    var arr = ['A',,'B'];
    arr[100] = 'C';
    f(arr);
    }

    window.onload = demo;
    </script>

    arr[1] member gets an explicit assignment; thus then you treat your
    array as an Object type, you see it as property "1" with value
    undefined.
    After arr[100] = 'C'; you're getting 96 members gap to the next defined
    value. But arr[3]...arr[99] never participated in any assignment
    operations. They are undefined and existing only in the abstract array
    continuum space. Therefore they are not reflected as object properties.
     
    VK, Sep 9, 2006
    #1
    1. Advertising

  2. VK wrote:
    > (see the post by ASM in the original thread; can be seen at
    >

    <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/3
    716384d8bfa1b0b>
    > as an option)
    >
    > As that is not in relevance to "new Array() vs []" question
    > or to the array performance, I dared to move it to a new thread.


    Or was it because you might avoid looking as much of a fool if you post
    this without a context as you would if you did.

    > Gecko takes undefined value strictly as per Book 4, Chapter 3,
    > Song 9 of Books of ECMA
    > :)
    > (Paragraph 4.3.9 of ECMAScript Language Specification, 3rd edition)
    > :-|


    The numbering of clauses in ECMA 262 has no relationship to paragraphs,
    books, chapters or songs.

    > <quote> The undefined value is a primitive value used when
    > a variable has not been assigned a value. </quote>


    And section 10.1.3 explains the assignment of the undefined value to
    instantiated variables. And no observable behaviour of _any_ ECMAScript
    implementations contradicts section 10.1.3.

    > As a matter complication JavaScript is the only language I
    > know where one can write:
    > var foo = undefined;


    The only thing specific to javascript in that statement is using - var -
    to declare a variable (and that may not be unique to javascript).

    > which is - strictly speaking - "keep foo but assign it the
    > value that foo was not assigned and never existed"


    Nonsense. The meaning of that statement is in two parts:-

    1. During 'variable instantiation' for the execution context; create
    a property named 'foo' on the Activation/Variable object for the
    execution context (with a DontDelete attribute) and assign the
    Undefined value to it.

    2. When execution of the code arrives at the assignment expression:
    The left-hand side is evaluated (into a Reference type with
    the Activation/Variable object as its 'base' property and 'foo'
    as its property name). The right hand side is evaluated to a
    value:
    The Identifier 'undefined' is resolved against the scope chain
    to give a Reference type. ECMAScript Edition 3 introduced a
    property of the global object with the name 'undefined' set to
    the Undefined value so the Reference type will likely have the
    global object as its 'base' property. In pre-ECMAScript edition
    3 environments that do not have a global 'undefined' property
    as an extension, or no programmer defined alternative has been
    created, the 'base' property of the Reference type will be null.

    The resulting Reference type is then passed to the internal
    GetValue function to recover a value (and exception will be
    thrown at this point if the Reference type has a null 'base'
    property).

    The value of the right hand side is then used with the Reference
    type from the left hand side in order to assign the value. The
    property of the Activation/Variable object named 'foo' is
    assigned the value of the right hand side (assuming no exception
    was thrown while recovering the value from the Identifier
    - undefined -).

    > which is - even more strictly
    > speaking - totally meaningless.


    What you wrote is meaningless, but that is just a manifestation of your
    not understanding javascript. The actual statement is doing nor more
    than (and no less than) evaluating a variable (undefined) and assigning
    its value to another variable (foo).

    > In case of an elision in an array initializer you *do* assign
    > values to each and every array member


    Rubbish. The evaluation of an elision will not result in any value being
    assigned to any element of an array except its - length - property in
    the event that the elision is not followed by an AssignmentExpression.

    > (Mr. Cornford would say something like
    > "[[Put]] method is called for each evaluation result").


    I am unlikely to say something that is utterly false.

    > This way
    > var arr = ['A',,'B']
    > really means
    > var arr = ['A',undefined,'B']


    No it does not. It is closer to:-

    var arr = new Array;
    arr[0] = 'A';;
    arr[2] = 'B';

    > with three array members explicetly assigned to the array
    > on the initialization stage.


    If that did happen it would be an implementation bug (as was the case in
    the firefox/Mozilla versions discussed in the other thread).

    > And each and every *assigned* array member is
    > reflected as an enumerable object property of the
    > underlaying Object object. To see the difference (and the
    > real sense of undefined value) try this:
    >
    > <script type="text/javascript">
    > function f(arg) {
    > for (var p in arg) {
    > window.alert(arg[p] || 'undefined');
    > }
    > window.alert('loops: ' + i);
    > }
    >
    > function demo() {
    > var arr = ['A',,'B'];
    > arr[100] = 'C';
    > f(arr);
    > }
    >
    > window.onload = demo;
    > </script>
    >
    > arr[1] member gets an explicit assignment;


    If it does then that would be in implementation bug.

    > thus then you treat your array as an Object type,


    There is no meaningful sense in which anyone could treat an array as not
    being an object type, as it always is of that type.

    > you see it as property "1" with value
    > undefined.
    > After arr[100] = 'C'; you're getting 96 members gap to
    > the next defined value. But arr[3]...arr[99] never participated
    > in any assignment operations. They are undefined and existing
    > only in the abstract array continuum space. Therefore they are
    > not reflected as object properties.


    So, apart from demonstrating your ability to shamelessly post material
    that is 100% factually false (that is; your assertions here about what
    ECMA 262 3rd Ed. says and means are the opposite of reality) what is
    your point?

    At lest the other thread came to the (correct) conclusion that the
    firefox/Mozilla behaviour described was an implementation bug.

    Richard.
     
    Richard Cornford, Sep 9, 2006
    #2
    1. Advertising

  3. VK

    VK Guest

    Richard Cornford wrote:
    > At lest the other thread came to the (correct) conclusion that the
    > firefox/Mozilla behaviour described was an implementation bug.


    I will definitely clarify this on Bugzilla and post the response here.
    Nevertheless in the matter of JavaScript engine behavior Mozilla is
    most likely to be by ECMAScript standard, at least it was since the
    beginning and until now.

    Before Mozilla team will give an answer, I say my humble opinion on
    this matter: it is another side effect of specification bug ;-)
    allowing undefined value to be *assigned* and being involved in some
    internal *assignment* operations.

    I'm glad that I don't need to make a choice how to treat a property
    with explicetly assigned value "this property doesn't exist and never
    existed".
    As a property with such value? (Gecko)
    As non-existing property? (IE and Co)

    Truthfully I would feel like to drop a coin, and then go to Switzerland
    to hit some dumb heads :)
     
    VK, Sep 9, 2006
    #3
  4. In article <>, VK
    <> writes

    <snip>
    >As a matter complication JavaScript is the only language I know where
    >one can write:
    > var foo = undefined;
    >which is - strictly speaking - "keep foo but assign it the value that
    >foo was not assigned and never existed" which is - even more strictly
    >speaking - totally meaningless.

    <snip>

    'Undefined' is a short way of saying the value it had when it was
    created and hadn't yet been assigned any different value. Assigning
    'undefined' (a keyword) is a way of restoring it to the initial state.

    I'm amazed that VK has the nerve to complain about a slightly awkward
    use of English.

    John
    --
    John Harris
     
    John G Harris, Sep 9, 2006
    #4
  5. VK wrote:
    > Richard Cornford wrote:
    >> At lest the other thread came to the (correct) conclusion
    >> that the firefox/Mozilla behaviour described was an
    >> implementation bug.

    >
    > I will definitely clarify this on Bugzilla and post the
    > response here.


    Why, when the tread you decided your post should not be added to already
    includes the bugzilla report (with its confirmation that it was a bug)?

    > Nevertheless in the matter of JavaScript engine behavior
    > Mozilla is most likely to be by ECMAScript standard, at
    > least it was since the beginning and until now.


    Not really. There are very few actual implementation bugs and those few
    are pretty evenly distributed.

    > Before Mozilla team will give an answer,


    Too late then.

    > I say my humble opinion on this matter:


    Nobody cares what your opinion is.

    > it is another side effect of specification bug ;-)


    Half-wit.

    > allowing undefined value to be *assigned* and being
    > involved in some internal *assignment* operations.


    Your inability to understand javascript is well established by now, but
    as a consistent, logical system with its behaviour fully specified (so
    completely understandable and predictable) that inability is a
    reflection only on your mental processes and nothing else.

    > I'm glad that I don't need to make a choice how to
    > treat a property with explicetly assigned value "this
    > property doesn't exist and never existed".


    That is the sort of nonsense that makes it clear why your opi9nion is of
    no value.

    > As a property with such value? (Gecko)
    > As non-existing property? (IE and Co)
    >
    > Truthfully I would feel like to drop a coin, and then go to
    > Switzerland to hit some dumb heads :)


    The specification is clear on the subject, Mozilla/Gecko is (or was)
    wrong and will be fixed so that it complies with the specification.

    Richard.
     
    Richard Cornford, Sep 9, 2006
    #5
  6. John G Harris wrote:
    <snip>
    > ... . Assigning 'undefined' (a keyword)


    Not a keyword, just an Identifier, and one that is likely to be resolved
    as the specification defined (ECMA 262 3re Ed. Section 15.1.1.3)
    property of the global object, which explicitly has the Undefined value.
    As it is not a keyword any function, formal parameter or variable could
    be named 'undefined' (along with any custom object property) and so
    replace or mask the global object's property. (The global 'undefined'
    property has the DontDelete and DontEnum attributes but it is not
    ReadOnly). Though obviously 'undefined' would be a spectacularly poor
    name to be giving to functions/parameters/variables/properties.

    <snip>
    > I'm amazed that VK has the nerve ...


    Ditto.

    Richard.
     
    Richard Cornford, Sep 9, 2006
    #6
  7. VK

    VK Guest

    > > I will definitely clarify this on Bugzilla and post the
    > > response here.

    >
    > Why, when the tread you decided your post should not be added to already
    > includes the bugzilla report (with its confirmation that it was a bug)?


    At the moment I was starting this thread the latest post by Cameron
    McCormack
    <http://groups.google.com/group/comp.lang.javascript/msg/45a87b8f172b03b4>
    was not shown yet in my browser. The thread ended up by Rob's post.

    I'm gratiful to Cameron McCormack for finding the relevant Bugzilla
    filing and for saving my time on that. So indeed it is confirmed to be
    a Gecko JavaScript engine bug: see
    <https://bugzilla.mozilla.org/show_bug.cgi?id=260106>
    So I was wrong and Microsoft was right in this case.

    Yet this bug existence (if translated from C++) is layed on the
    situation of an "assignment of the value of no assignment" and
    indexing troubles after that. Doesn't make myself neither Mozilla right
    of course.
     
    VK, Sep 9, 2006
    #7
  8. VK wrote:
    <snip>
    > So I was wrong

    <snip>

    That was inevitable from the moment you posted. It is just a pity you
    waste so much time (that could be better given to more deserving cases)
    finding out why you were inevitably wrong. Just understand; you
    conception of javascript is largely a fictional product of your own
    deranged imagination and has no more than a superficial relationship
    with reality. If you would finally accept that truth you might be able
    to do something about acquiring a worthwhile understanding of the
    subject, or at leas to stop wasting so much of other peoples time by
    keeping your lunacy to yourself.

    Richard.
     
    Richard Cornford, Sep 9, 2006
    #8
  9. VK

    Guest

    Richard,
    it looks like there are only morons surrounding you.
    Maybe you are too perfect for this world? ;o)
     
    , Sep 10, 2006
    #9
  10. wrote:
    > Richard,
    > it looks like there are only morons surrounding you.
    > Maybe you are too perfect for this world? ;o)


    What is up, you have something against the propagation of accurate
    information?

    Richard.
     
    Richard Cornford, Sep 10, 2006
    #10
  11. VK

    Guest

    Richard Cornford напиÑав:
    > wrote:
    > > Richard,
    > > it looks like there are only morons surrounding you.
    > > Maybe you are too perfect for this world? ;o)

    >
    > What is up, you have something against the propagation of accurate
    > information?
    >
    > Richard.

    I never was against an accurate information. But it is not a pleasure
    to talk with person who shows to everyone: "there is only two opinions:
    my opinion and wrong opinion".
    I believe that you are real JS guru, but sometimes you realy rough with
    people. BTW you are not the only man here who love and know JS.
     
    , Sep 10, 2006
    #11
  12. wrote:
    > Richard Cornford Ð½Ð°Ð¿Ð¸Ñ Ð°Ð²:
    >> wrote:
    >>> it looks like there are only morons surrounding you.
    >>> Maybe you are too perfect for this world? ;o)

    >>
    >> What is up, you have something against the propagation
    >> of accurate information?
    >>
    >> Richard.

    > I never was against an accurate information. But it is
    > not a pleasure to talk with person who shows to
    > everyone: "there is only two
    > opinions: my opinion and wrong opinion".


    Where is the opinion here? VK's original post was 100% the opposite of
    the truth and - undefined - is not a keyword in javascript.

    > I believe that you are real JS guru,


    Anyone who would want to be labelled "guru" should be regarded with
    extreme suspicion (with the possible exception of Fakirs and related
    Indian mystics).

    > but sometimes you realy rough with people.


    Rarely without reason.

    > BTW you are not the only man here who love and know JS.


    Your point?

    Richard.
     
    Richard Cornford, Sep 10, 2006
    #12
  13. VK

    VK Guest

    VK wrote:
    > So indeed it is confirmed to be
    > a Gecko JavaScript engine bug: see
    > <https://bugzilla.mozilla.org/show_bug.cgi?id=260106>
    > So I was wrong and Microsoft was right in this case.


    *IMHO*


    After thinking it over again tonight, I see no bug in Mozilla. But I
    see a specification bug in the referenced ECMAScript section 11.1.4
    which is in turn a reflection of erroneus decision once made to allow
    undefined value to be *assigned*.


    Quote 1
    4.3.9 Undefined Value
    The undefined value is a primitive value used
    when a variable has not been assigned a value.


    Quote 2
    8.1 The Undefined Type
    The Undefined type has exactly one value, called undefined.
    Any variable that has not been assigned a value has
    the value undefined.


    Quote 3
    11.1.4 Array Initialiser, preface
    .... Elided array elements are not defined.


    Quote 4
    11.1.4 Array Initialiser, production
    (VK: for say [,1,2] array initializer)
    ....
    1. Create a new array as if by the expression new Array().
    2. Evaluate Elision; if not present, use the numeric value zero.
    3. Call the [[Put]] method of Result(1) with arguments
    "length" and Result(2).
    4. Return Result(1).
    ....


    Quote 5
    8.6.2.2 [[Put]] (P, V)
    (VK: referenced on step 3 in the previous quote)
    When the [[Put]] method of O is called with property P and value V,
    the following steps are taken:
    1. Call the [[CanPut]] method of O with name P.
    2. If Result(1) is false, return.
    3. If O doesn't have a property with name P, go to step 6.
    4. Set the value of the property to V. The attributes of the property
    are not changed.
    5. Return.
    6. Create a property with name P, set its value to V and give it empty
    attributes.
    7. Return.


    This way I see a specification bug in 11.1.4 where the preface is in
    contradiction with the production. By going by the production, it is
    not possible to have "not defined" members in place of elision. There
    is an explicit assignment (set) operation involved, therefore we only
    can have *members explicetly initialized with undefined value*.
    In this respect if we want
    arr = [,1,2];
    to produce an array that can be treated it as an object with two
    properties ("1" and "2", but not "0"): then we also have to request
    that
    obj = {};
    obj.foo = undefined;
    would result in an object with no enumerable properties (no <foo>
    property).
    Technically by the production schema these are totally the same, but no
    one seems filing a bug for the later.

    That's again: there is a cardinal difference between i) something that
    exists and it has explicetly assigned undefined value and ii) something
    that doesn't exists anymore or never existed.
    Section 11.1.4 requires two opposite things in preface section and in
    production section, so it's the programmer's choice what to follow.

    Here some code I've made while making my mind together :) :


    <html>
    <head>
    <title>Untitled Document</title>
    <meta http-equiv="Content-Type" content="text/html;
    charset=iso-8859-1">
    <script type="text/javascript">
    var br = '\n';
    var p = br + br;

    function test1(out) {
    out.value = 'Test 1' + p;

    // variable <foo> is explicetly initialized
    // with undefined value:
    var foo = undefined;

    // variable <bar> simply doesn't exist
    // neither in local nor in global scopes

    out.value+= (typeof foo) + br; // "undefined"
    out.value+= (typeof bar) + br; // "undefined"

    // but later:
    try {
    out.value+= (foo == 0) + br; // false
    out.value+= (bar == 0) + br; // run-time error
    }
    catch(e) {
    out.value+= 'Run-time error: ' + e.message + br;
    }
    }


    function test2(out) {
    out.value = 'Test 2' + p;

    var obj = new Object();

    // property <foo> is explicetly initialized
    // with undefined value:
    obj.foo = undefined;

    // property <bar> simply doesn't exist
    // in <obj> object

    out.value+= (typeof obj.foo) + br; // "undefined"
    out.value+= (typeof obj.bar) + br; // "undefined"

    // but only one enumerable property <foo> exists:
    for (var prop in obj) {
    out.value+= prop + ' = ' + obj[prop] + br;
    }
    }


    function test3(out) {
    out.value = 'Test 3' + p;

    // initializing array with elision:
    var arr = [,1,2];

    out.value+= 'length: ' + arr.length + p; // 3

    for (var i=0; i<arr.length; i++) {
    out.value+= 'arr['+i+'] = ' + arr + br;
    }

    out.value+= p;

    for (var prop in arr) {
    out.value+= 'arr.'+prop+' = ' + arr[prop] + br;
    }

    out.value+= p;


    delete arr[0];
    for (var prop in arr) {
    out.value+= 'arr.'+prop+' = ' + arr[prop] + br;
    }

    }
    </script>
    </head
    ><body
    ><form method="post" action=""
    ><textarea name="out" cols="64" rows="16"></textarea
    ><br
    ><input type="button" name="b1" value="Test 1"

    onClick="test1(this.form.out)"
    ><input type="button" name="b2" value="Test 2"

    onClick="test2(this.form.out)"
    ><input type="button" name="b3" value="Test 3"

    onClick="test3(this.form.out)"
    ></form
    ></body
    ></html>
     
    VK, Sep 10, 2006
    #13
  14. VK wrote:
    > VK wrote:
    >> So indeed it is confirmed to be
    >> a Gecko JavaScript engine bug: see
    >> <https://bugzilla.mozilla.org/show_bug.cgi?id=260106>
    >> So I was wrong and Microsoft was right in this case.

    >
    > *IMHO*


    Your opinions are worthless, for reasons that will once again become
    clear.

    > After thinking it over again tonight,


    Don't confuse your mental processes with thinking (at least in the sense
    that everyone else uses the term).

    > I see no bug in Mozilla.


    So where everyone else sees a bug, including the people who wrote the
    script engine for Mozilla, you don't see one.

    > But I see a specification bug in the referenced
    > ECMAScript section 11.1.4 which is in turn a
    > reflection of erroneus decision once made to allow
    > undefined value to be *assigned*.
    >
    > Quote 1
    > 4.3.9 Undefined Value
    > The undefined value is a primitive value used
    > when a variable has not been assigned a value.


    The mechanism for which ("used when a variable has not been assigned a
    value") is laied out in section 10.1.3 under "Variable Instantiation".

    > Quote 2
    > 8.1 The Undefined Type
    > The Undefined type has exactly one value, called undefined.
    > Any variable that has not been assigned a value has
    > the value undefined.
    >
    >
    > Quote 3
    > 11.1.4 Array Initialiser, preface
    > ... Elided array elements are not defined.


    The distinction between a 'variable', as referred to in section 4.3.9,
    and an array element being significant.

    > Quote 4
    > 11.1.4 Array Initialiser, production
    > (VK: for say [,1,2] array initializer)


    So the applicable productions would be the production:
    ArrayLiteral : [ ElementList , Elison<opt> ]
    - including the production:
    ElementList: Elision<opt> AssignmentExpression.

    > ...
    > 1. Create a new array as if by the expression new Array().
    > 2. Evaluate Elision; if not present, use the numeric value zero.


    This is not the algorithm for - [,1,2] -, it is the algorithm for -
    [,,] - and the like. The production:
    ArrayLiteral: [ Elision<opt> ]

    If you are going to make statements about the interpretation of ECMA 262
    you should at lest refer to the relevant sections.

    > 3. Call the [[Put]] method of Result(1) with arguments
    > "length" and Result(2).


    Note that the property name being assigned to here is "lenght".

    > 4. Return Result(1).
    > ...
    >
    > Quote 5
    > 8.6.2.2 [[Put]] (P, V)

    <snip>
    The special [[Put]] method of Arrays is defined in section 15.4.5.1 and
    differs from the standard object [[Put]] method quoted here.

    > This way I see a specification bug in 11.1.4


    You read the wrong ArrayLiteral algorithm(s) and use the wrong [[Put]]
    method and you see a "specification bug"?

    > where the preface is in
    > contradiction with the production.


    Is that the production you referred to or the applicable productions?

    > By going by the production, it is not possible to have
    > "not defined" members in place of elision.


    You omitted to cover the productions for Elision:-

    The production Elision :, is evaluated as follows:
    1. Return the numeric value 1.

    The production Elision : Elision, is evaluated as follows:
    1. Evaluate Elision.
    2. Return (Result(1)+1).

    So in your cited algorithm, applied to [,,]:-

    | 2. Evaluate Elision; if not present, use the numeric value zero.

    - the numeric value is going to be two. And then:-

    | 3. Call the [[Put]] method of Result(1) with arguments
    | "length" and Result(2).

    - writes the value 2 to the length property of the array, without
    defining, or assigning to, any actual array elements.

    So in what sense if it "not possible to have "not defined" members in
    place of elision"? Here the length is 2 and the array has no other
    defined properties, as a result of two Elisions in the Array literal.

    > There is an explicit assignment (set) operation involved,


    To the 'length' property.

    > therefore we only can have *members explicetly
    > initialized with undefined value*.


    You have not shown any.

    > In this respect if we want
    > arr = [,1,2];
    > to produce an array that can be treated it as an object
    > with two properties ("1" and "2", but not "0"): then
    > we also have to request
    > that
    > obj = {};
    > obj.foo = undefined;
    > would result in an object with no enumerable properties
    > (no <foo> property).


    Such has not been demonstrated here. In the case of the array no
    explicit assignment is made to a property with the name '0', while in
    the case of the object a property named 'foo' has been explicitly
    assigned a value.

    > Technically by the production schema these are totally
    > the same,


    Even if they were, and they are not, how would you know? What you
    understand of what you read differs significantly from the meaning of
    what you read.

    > but no one seems filing a bug for the later.


    OK. There is a mental processing bug in VK's mind that leaves him
    incapable of perceiving reality. You may consider the bug reoprted to
    the responsible party.

    <snip>
    > Section 11.1.4 requires two opposite things in preface
    > section and in production section, so it's the
    > programmer's choice what to follow.


    No contradiction exists. Elision evaluation either only changes the -
    length - property of an array or it only offsets the index where the
    results of AssignmentExpressions are stored (with consequential effects
    on the - length -).

    > Here some code I've made while making my mind
    > together :) :

    <snip>

    LOL

    Richard.
     
    Richard Cornford, Sep 10, 2006
    #14
  15. VK wrote:

    [snip]

    > After thinking it over again tonight, I see no bug in Mozilla.


    Somehow, I knew you'd write that.

    Really VK, why the hell do you post to this group? How can you possibly
    think that you are able to assist anyone when you blatantly haven't got
    a clue about this language?

    > But I see a specification bug in the referenced ECMAScript section
    > 11.1.4 ...


    You would.

    > 4.3.9 Undefined Value
    > The undefined value is a primitive value used
    > when a variable has not been assigned a value.


    Which does not say that such a value may not be assigned to a property.

    > 8.1 The Undefined Type
    > The Undefined type has exactly one value, called undefined.
    > Any variable that has not been assigned a value has
    > the value undefined.


    Ditto.

    > 11.1.4 Array Initialiser, preface
    > ... Elided array elements are not defined.


    Which means that no property is created for that object where the
    elision occurs. The bug in Mozilla is that it does create such a property.

    > 11.1.4 Array Initialiser, production
    > (VK: for say [,1,2] array initializer)
    > ...
    > 1. Create a new array as if by the expression new Array().
    > 2. Evaluate Elision; if not present, use the numeric value zero.
    > 3. Call the [[Put]] method of Result(1) with arguments
    > "length" and Result(2).
    > 4. Return Result(1).
    > ...


    You've quoted the wrong production for the proposed ArrayLiteral. The
    correct /series/ of productions would be:

    The production ArrayLiteral : [ ElementList ] is evaluated as
    follows:
    1. Evaluate ElementList.
    2. Return Result(1).

    The production ElementList : ElementList , Elision(opt)
    AssignmentExpression is evaluated as follows:
    1. Evaluate ElementList.
    2. Evaluate Elision; if not present, use the numeric value
    zero.
    3. Evaluate AssignmentExpression.
    4. Call GetValue(Result(3)).
    5. Call the [[Get]] method of Result(1) with argument
    "length".
    6. Call the [[Put]] method of Result(1) with arguments
    (Result(2)+Result(5)) and Result(4).
    7. Return Result(1)

    (where the Elision is omitted) and:

    The production ElementList : Elision(opt) AssignmentExpression
    is evaluated as follows:
    1. Create a new array as if by the expression new Array().
    2. Evaluate Elision; if not present, use the numeric value
    zero.
    3. Evaluate AssignmentExpression.
    4. Call GetValue(Result(3)).
    5. Call the [[Put]] method of Result(1) with arguments
    Result(2) and Result(4).
    6. Return Result(1)

    (where Elision is evaluated and returns a value of 1).

    Following those steps, a new Array object is created, and the values 1
    and 2 are assigned to properties '1' and '2', respectively. No property
    '0' is created, therefore it cannot be enumerated.

    > 8.6.2.2 [[Put]] (P, V)


    Moron. That's the wrong [[Put]] method.

    [snip]

    > This way I see a specification bug in 11.1.4 where the preface is in
    > contradiction with the production.


    Perhaps if you knew how to read the specification, you wouldn't be so
    confused.

    > By going by the production, it is not possible to have "not defined"
    > members in place of elision.


    Yes, it is. An Elision that occurs at the start, or amongst other
    AssignmentExpression productions, determines what property name is used
    when assigning the result of evaluating each AssignmentExpression. A
    trailing Elision affects the final value assigned to the length property
    of the Array object. An Elision production does not cause an assignment
    by itself:

    The production Elision : , is evaluated as follows:
    1. Return the numeric value 1.

    The production Elision : Elision , is evaluated as follows:
    1. Evaluate Elision.
    2. Return (Result(1)+1).

    except where it is the only production to be evaluated in the
    ArrayLiteral, in which case only the length property is affected.

    > There is an explicit assignment (set) operation involved, therefore
    > we only can have *members explicetly initialized with undefined
    > value*.


    Give up before you give yourself a headache.

    [snip]

    Mike
     
    Michael Winter, Sep 10, 2006
    #15
  16. VK

    VK Guest

    Michael Winter wrote:
    > Really VK, why the hell do you post to this group? How can you possibly
    > think that you are able to assist anyone when you blatantly haven't got
    > a clue about this language?


    You know what, Dear Sir, you've got on my *really* bad day today. So
    right why would not address both of above questions to yourselve as the
    most applicable person around here?

    <snip>
    > Elision that occurs at the start, or amongst other
    > AssignmentExpression productions, determines what property name is used
    > when assigning the result of evaluating each AssignmentExpression.


    Moron, you're mixing again hell out of an object property production
    and an array member production (besides reading and quoting specs like
    a drunk vagabond). In JavaScript array (viewed from the objective point
    of view) *index* becomes property name, elision provides the *value*
    for the that property.
    var arr = [1,,2];
    in terms of object/property/value is
    var obj = {'0':1, '1':undefined, '2':2}
    and
    var arr = [,1,2];
    in terms of object/property/value is
    var obj = {'0':undefined, '1':undefined, '2':2}
    with some conclusions to make about this "bug" (if you are able to make
    any independent conclusions).


    P.S. I'm almost sorry to start both this one and <this> discussions.
    The inevitable obligation to mit over and over again the same narrow
    set of morons insured that they know everything possible about
    JavaScript (and whatever they don't is either wrong or useless) - this
    obligation takes sometimes too much of energy to spent w/o many
    benefits.
     
    VK, Sep 10, 2006
    #16
  17. VK wrote:
    > Michael Winter wrote:
    >> Really VK, why the hell do you post to this group? How can you
    >> possibly think that you are able to assist anyone when you blatantly
    >> haven't got a clue about this language?

    >
    > You know what, Dear Sir, you've got on my *really* bad day today.


    And in English that would be?

    > So right why would not address both of above questions to yourselve
    > as the most applicable person around here?


    More gibberish.

    > <snip>
    >> Elision that occurs at the start, or amongst other
    >> AssignmentExpression productions, determines what property
    >> name is used when assigning the result of evaluating each
    >> AssignmentExpression.

    >
    > Moron, you're mixing again hell out of an object property production
    > and an array member production (besides reading and quoting specs
    > like a drunk vagabond).


    Then you don't see that Mike is 100% on the money?

    > In JavaScript array


    Remember that when you asserted that you were a "world expert" on
    javascript arrays you immediately had to take that back and make out it
    was intended to be humorous in order to avoid looking a complete fool.

    > (viewed from the objective point of view)


    Can someone as deluded as you view anything from an objective point of
    view?

    > *index* becomes property name, elision provides the *value*
    > for the that property.


    No. Elision on its own only adjusts the - length - property, and
    Elision followed by AssignmentExpression determines the array index
    used to store the value of the assignment expression:-

    The production
    ElementList : ElementList , Elisionopt AssignmentExpression
    is evaluated as follows:

    1. Evaluate ElementList.
    2. Evaluate Elision; if not present, use the numeric value zero.

    Evaluate Elision gives a number equivilnet ot the number of elisions,
    else zero is used if there are no Elisions.

    3. Evaluate AssignmentExpression.

    Evaluate AssignmentExpression (giving Result(3) ) determines the value
    of the assignment expression if it is not a Reference type.

    4. Call GetValue(Result(3)).

    Call GetValue(Result(3)) turns Reference types into actual values, but
    does not alter non-Reference type values.

    5. Call the [[Get]] method of Result(1) with argument "length".

    Result(5) is the length of the array following the evaluation of
    ElementList in step one.

    6. Call the [[Put]] method of Result(1) with arguments
    (Result(2)+Result(5)) and Result(4).

    Result(1) is the array, (Result(2)+Result(5)) is a number determined by
    the number of Elisions plus the current length of the array and is used
    as the property name here, and Result(4) is the value of the
    AssignmentExpression.

    7. Return Result(1)

    There is no question of the elision providing any values for array
    elements, just influencing the 'array index' property named used and
    consequently the - length - property of the array. (and the same goes
    for all the other productions)

    > var arr = [1,,2];
    > in terms of object/property/value is
    > var obj = {'0':1, '1':undefined, '2':2}


    No, the equivalent in terms of object Initialisers is:-

    var obj = {'0':1, '2':2}

    - no value will be assigned to any property with the name '1'.

    > and
    > var arr = [,1,2];
    > in terms of object/property/value is
    > var obj = {'0':undefined, '1':undefined, '2':2}


    No, the equivalent in terms of object Initialisers is:-

    var obj = {'1':1, '2':2}

    - no value will be assigned to any property with the name '0'.

    > with some conclusions to make about this "bug" (if you are
    > able to make any independent conclusions).


    The conclusion about the bug was made some time ago: JavaScript(tm) 1.5
    has an implementation bug that will be fixed.

    > P.S. I'm almost sorry to start both this one and <this>
    > discussions.


    You have made yourself look a fool in public again and you are only
    almost sorry? It is no wonder that you manage to make yourself look
    such a fool with such relentless frequency.

    > The inevitable obligation to mit over and over
    > again the same narrow set of morons insured that they know
    > everything possible about JavaScript (and whatever they
    > don't is either wrong or useless) - this obligation takes
    > sometimes too much of energy to spent w/o many benefits.


    When you cite the wrong algorithms, misinterpret those algorithms, draw
    false conclusions and fail to comprehend corrections any time wasting
    that is going on is entirely down to you.

    Yes the entire exercise has no benefit for you, but that is because you
    are incapable of seeing that you are wrong when you are wrong (at least
    without having the truth repeatedly shoved down your throat, and often
    not even then).

    Richard.
     
    Richard Cornford, Sep 10, 2006
    #17
  18. VK wrote:

    [snip]

    > You know what, Dear Sir, you've got on my *really* bad day today.


    LOL

    [snip]

    >> [An] Elision that occurs at the start, or amongst other
    >> AssignmentExpression productions, determines what property name is
    >> used when assigning the result of evaluating each
    >> AssignmentExpression.

    >
    > Moron, you're mixing again hell out of an object property production
    > and an array member production (besides reading and quoting specs
    > like a drunk vagabond).


    Even you should be able to see that what I quoted came only from section
    11.1.4.

    It's not my fault that you can't understand the formal grammar used in
    the specification.

    > In JavaScript array (viewed from the objective point of view) *index*
    > becomes property name,


    And where do you think the index comes from?

    If you walk, step-by-step, through the algorithm of each production I
    posted, you can see quite clearly how elisions affect array creation. If
    you actually try that, don't assume that what happens is what you think
    is supposed to happen (because you idea of things is simply wrong), just
    do it as the algorithm specifies.

    > elision provides the *value* for the that property.


    If you care to think about that statement, you should see that it is
    absolutely false.

    An Elision production evaluates to a number. On its own, 1:

    The production Elision : , is evaluated as follows:
    1. Return the numeric value 1.

    Where multiple elisions occur, they are added:

    The production Elision : Elision , is evaluated as follows:
    1. Evaluate Elision.
    2. Return (Result(1)+1).

    The only property value that elisions affect is the length property,
    either directly for trailing elisions, or indirectly by altering the
    value passed to the internal (Array) [[Put]] method when assigning the
    value of an evaluated AssignmentExpression production.

    > var arr = [1,,2];
    > in terms of object/property/value is
    > var obj = {'0':1, '1':undefined, '2':2}


    No, it isn't.

    > and
    > var arr = [,1,2];
    > in terms of object/property/value is
    > var obj = {'0':undefined, '1':undefined, '2':2}


    Definitely not!

    [snip]

    Mike
     
    Michael Winter, Sep 10, 2006
    #18
  19. VK

    VK Guest

    > > You know what, Dear Sir, you've got on my *really* bad day today.
    >
    > LOL


    I'm much better now. I should remember that going beyond the netiquette
    restores your stamina really well some times. ;-) The only problem is
    do not get too used to such remedie: like some of my opponents did.

    What is the difference between a documentation frick and a real
    language specialist (excluding myself from either group)? A
    documentation frick will quote, and quote... and quote. That is the
    only thing you'll possibly get on your questions. However you're
    asking, the thinking process of your opponent is being blocked: because
    on each situation he has a relevant or not so relevant quote from the
    book.

    Just go by your road. I've got my monthly limit of quotes from the
    Books of ECMA, no more for a while.

    btw don't forget to file another "bug" then: Mozilla doesn't treat
    properly array members initialized with undefined value.

    <script type="text/javascript">
    var prop = null;

    var arr1 = [1,,,2]
    var arr2 = [1,undefined,undefined,2]

    for (var prop in arr1) {
    alert(prop + ' = ' + arr1[prop]);
    }

    for (var prop in arr2) {
    alert(prop + ' = ' + arr2[prop]);
    }
    </script>
     
    VK, Sep 10, 2006
    #19
  20. VK wrote:
    >>> You know what, Dear Sir, you've got on my *really* bad

    >> day today.
    >>
    >> LOL

    >
    > I'm much better now. I should remember that going beyond the
    > netiquette restores your stamina really well some times. ;-) The only
    > problem is do not get too used to such remedie: like some of my
    > opponents did.
    >
    > What is the difference between a documentation frick
    > and a real language specialist (excluding myself from
    > either group)? A documentation frick will quote, and
    > quote... and quote.


    You started the quoting. You quoted algorithms and text, and then you
    made false assertions (of non-existent contradictions), apparently based
    on misinterpreting the wrong algorithms.

    > That is the
    > only thing you'll possibly get on your questions.


    What was your question? It seems to me that you made a series of false
    statements, declared yourself wrong, recanted and declared everything
    else wrong and now are unwilling to accept that your first declaration
    of culpability was the inevitably correct one.

    > However you're asking, the thinking process of your
    > opponent is being blocked: because on each situation
    > he has a relevant or not so relevant quote from the book.


    You asserted that there was a contradiction in the specification and you
    asserted that the algorithms stated that an elision would assign an
    'array index' property to an array. How do you expect to be shown that
    no contraditi9on exists and no 'array index' properties are assigned in
    the algorithms than to be shown, and re-shown the actual text stating
    the opposite of what you asserted it said?

    Of course rather than admitting (or probably even recognising) that you
    were wrong yet again, you would rather suggest that the style of
    argument you initially introduced is only significant when it is you
    (mis)interpreting the text.

    > Just go by your road. I've got my monthly limit of quotes
    > from the Books of ECMA, no more for a while.
    >
    > btw don't forget to file another "bug" then: Mozilla
    > doesn't treat properly array members initialized with
    > undefined value.


    "Mozilla doesn't treat properly array members initialized with undefined
    value" what, how? In what way does Mozilla not "treat" "property array
    members initalized with undeifned"? Indeed what would Mozilla have to do
    in order to 'treat' one? If you are going to write this nonsense the
    least you could do is carry your sentences through to completion (or is
    you though process so disjointed that could not achieve even that).

    > <script type="text/javascript">
    > var prop = null;
    >
    > var arr1 = [1,,,2]
    > var arr2 = [1,undefined,undefined,2]
    >
    > for (var prop in arr1) {
    > alert(prop + ' = ' + arr1[prop]);
    > }
    >
    > for (var prop in arr2) {
    > alert(prop + ' = ' + arr2[prop]);
    > }
    > </script>


    Given that the known (and reported) bug explains the outcome for -
    aray1 - and the outcome for - array2 - is entirely in accordance with
    the specification, where is this 'another "bug"' you allude to?

    It is not, by any chance, another figment of your deranged imagination
    is it?

    Richard.
     
    Richard Cornford, Sep 10, 2006
    #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. Mantorok Redgormor
    Replies:
    70
    Views:
    1,825
    Dan Pop
    Feb 17, 2004
  2. [rob desbois]
    Replies:
    2
    Views:
    297
    [rob desbois]
    Apr 15, 2008
  3. sonic
    Replies:
    5
    Views:
    99
  4. -Lost
    Replies:
    13
    Views:
    384
    Richard Cornford
    Jan 31, 2007
  5. Replies:
    2
    Views:
    502
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page