jQuery Query about comparing jQuery references

Discussion in 'Javascript' started by Aaron Gray, Jul 25, 2008.

  1. Aaron Gray

    Aaron Gray Guest

    There does not seem too be anyway to test if two jQuery references are the
    same element.

    Given :-

    ... <div id="1"></div> ....

    Then :-

    alert( $("#1") == $("#1"))

    return false.

    jQuery's eq does not seem to help either.

    jQuery's site seems overloaded and it being intermittent, so I would not
    look for help from there right now !

    Aaron
    Aaron Gray, Jul 25, 2008
    #1
    1. Advertising

  2. Aaron Gray

    Henry Guest

    On Jul 25, 3:41 pm, Aaron Gray wrote:
    > There does not seem too be anyway to test if two jQuery
    > references are the same element.
    >
    > Given :-
    >
    > ... <div id="1"></div> ....
    >
    > Then :-
    >
    > alert( $("#1") == $("#1"))
    >
    > return false.


    As would be expected because each JQuery request creates a new object
    to wrap the result, and so each will be distinct from all others in
    terms of identity.

    Incidentally, in HTML it is not valid for the value of an ID attribute
    to commence with a decimal digit, so assuming "#1" is intended to
    represent a CSS ID selector you have a system that you should have no
    expectation of working correctly/consistently (at all, and
    particularly across browsers).

    > jQuery's eq does not seem to help either.


    What leads you to believe it would?

    If you could access the actual DOM nodes retrieved, ascertain that
    each retrieval contained the same number, and then verify that each
    corresponding node had the same identity across the two retreated
    results then you could determine equality (in some sense).

    It would be a lot more efficient to just use document.getElementById
    and compare the identity of the results directly.

    > jQuery's site seems overloaded and it being intermittent,
    > so I would not look for help from there right now !


    Right now?
    Henry, Jul 25, 2008
    #2
    1. Advertising

  3. Aaron Gray

    Aaron Gray Guest

    "Henry" <> wrote in message
    news:...
    > On Jul 25, 3:41 pm, Aaron Gray wrote:
    >> There does not seem too be anyway to test if two jQuery
    >> references are the same element.
    >>
    >> Given :-
    >>
    >> ... <div id="1"></div> ....
    >>
    >> Then :-
    >>
    >> alert( $("#1") == $("#1"))
    >>
    >> return false.

    >
    > As would be expected because each JQuery request creates a new object
    > to wrap the result, and so each will be distinct from all others in
    > terms of identity.


    Yes, and no way to overload the '==' operator in Javascript, unlike in C++.

    > Incidentally, in HTML it is not valid for the value of an ID attribute
    > to commence with a decimal digit, so assuming "#1" is intended to
    > represent a CSS ID selector you have a system that you should have no
    > expectation of working correctly/consistently (at all, and
    > particularly across browsers).


    Ah, I will bear that in mind. I have dumped using id's in anycase prefering
    to store element "references" instead which is less overhead.

    >> jQuery's eq does not seem to help either.

    >
    > What leads you to believe it would?


    Dunno, its the only thing with a name that suggest it may help.

    So I have dumped playing with jQuery now as it cannot even compare two
    elements, poor show.

    > If you could access the actual DOM nodes retrieved, ascertain that
    > each retrieval contained the same number, and then verify that each
    > corresponding node had the same identity across the two retreated
    > results then you could determine equality (in some sense).


    Right

    > It would be a lot more efficient to just use document.getElementById
    > and compare the identity of the results directly.


    Yes thats what I have opted for.

    >> jQuery's site seems overloaded and it being intermittent,
    >> so I would not look for help from there right now !

    >
    > Right now?


    When I was last using it, it 404'ed a few times, took minutes to display a
    page on others.

    Anyway regarding my library intentions I have descided to prototype lots of
    different widgets and see whats really required of a base library. Then
    prototype them throught several phases, first a just working prototype that
    relys on HTML code for its layout, then another version that is created from
    JSON like script, then look at integrating then widgets into a JSON (with
    functions) like driven UI with AJAX and POST sending.

    So far started with a TreeControl, and an Accordian.

    Aaron
    Aaron Gray, Jul 25, 2008
    #3
  4. Aaron Gray

    dhtml Guest

    On Jul 25, 11:08 am, "Aaron Gray" <> wrote:
    > "Henry" <> wrote in message
    >
    > news:...
    >
    >
    >
    > > On Jul 25, 3:41 pm, Aaron Gray wrote:
    > >> There does not seem too be anyway to test if two jQuery
    > >> references are the same element.

    >
    > >> Given :-

    >
    > >>   ...  <div id="1"></div>  ....

    >
    > >> Then :-

    >
    > >>     alert( $("#1") == $("#1"))

    >
    > >> return false.

    >
    > > As would be expected because each JQuery request creates a new object
    > > to wrap the result, and so each will be distinct from all others in
    > > terms of identity.

    >
    > Yes, and no way to overload the '==' operator in Javascript, unlike in C++.
    >
    > > Incidentally, in HTML it is not valid for the value of an ID attribute
    > > to commence with a decimal digit, so assuming "#1" is intended to
    > > represent a CSS ID selector you have a system that you should have no
    > > expectation of working correctly/consistently (at all, and
    > > particularly across browsers).

    >
    > Ah, I will bear that in mind. I have dumped using id's in anycase prefering
    > to store element "references" instead which is less overhead.
    >
    > >> jQuery's eq does not seem to help either.

    >
    > > What leads you to believe it would?

    >
    > Dunno, its the only thing with a name that suggest it may help.
    >


    That is not what jquery.fn.eq is intended for.

    The source code will tell all the details of what the code does.

    However, sometimes when the code is complicated (like jquery), it is
    easier to look at the documentation.

    > So I have dumped playing with jQuery now as it cannot even compare two
    > elements, poor show.
    >


    I would interpret that as you dumped jquery because you don't know how
    to use it.

    Check out the jquery user group. If you're interested in learning how
    jquery works, or contributing, join the jquery developers group;
    http://docs.jquery.com/Core
    http://groups.google.com/group/jquery-dev


    > > If you could access the actual DOM nodes retrieved, ascertain that
    > > each retrieval contained the same number, and then verify that each
    > > corresponding node had the same identity across the two retreated
    > > results then you could determine equality (in some sense).

    >
    > Right
    >


    With a long collection, that would be quite inefficient to do. N^2,
    when lengths were equivalent. Of course, if lengths were not
    equivalent, then it would be very easy to determine.

    // If lengths are different, the two collections
    // cannot be equal.
    if(result1.length != result2.length) return false;

    Garrett

    >
    > Aaron
    dhtml, Jul 25, 2008
    #4
  5. Aaron Gray

    Aaron Gray Guest

    <snip>

    Damb newsreader not quoting...

    I did not like jQuery from the start the $() thingy really put me off. Then
    looking at the code its horrible. Then try using it, there are things you
    just cannot do. Looked at the code looked at the documentation, dont like
    it, rather write my own.

    To do a document.getElementById takes have a page of code with recursion
    involved, thats a no go for me.

    Aaron
    Aaron Gray, Jul 25, 2008
    #5
  6. Aaron Gray wrote:
    > "Henry" <> wrote:
    >> On Jul 25, 3:41 pm, Aaron Gray wrote:
    >>> There does not seem too be anyway to test if two jQuery
    >>> references are the same element.
    >>>
    >>> Given :-
    >>>
    >>> ... <div id="1"></div> ....
    >>>
    >>> Then :-
    >>>
    >>> alert( $("#1") == $("#1"))
    >>>
    >>> return false.

    >> As would be expected because each JQuery request creates a new object
    >> to wrap the result, and so each will be distinct from all others in
    >> terms of identity.

    >
    > Yes, and no way to overload the '==' operator in Javascript, unlike in C++.


    However, the jQuery object in question might provide a property or method to
    return the target element object of each wrapped object; a good API would.
    Then the property values or the return values of these method calls could be
    compared as if no wrapper object was present.

    Despite jQuery's provably bad code quality, as the beginner that you are you
    should be very slow to attribute things not being possible to anything else
    but your own lack of experience.

    >>> jQuery's eq does not seem to help either.

    >> What leads you to believe it would?

    >
    > Dunno, its the only thing with a name that suggest it may help.
    >
    > So I have dumped playing with jQuery now as it cannot even compare two
    > elements, poor show.


    This would not be a logical design decision. It is not unreasonable of
    jQuery to wrap host objects if it is to provide its own interface to them;
    in fact, given the option of augmenting host objects instead, a wrapper
    object is definitely the better alternative because, in contrast, it is
    reliable.

    >> It would be a lot more efficient to just use document.getElementById
    >> and compare the identity of the results directly.

    >
    > Yes thats what I have opted for.


    However error-prone and inefficient jQuery's wrapper method, using
    document.getElementById() directly requires you to provide your own runtime
    feature test before each call if your application is not to be inherently
    error-prone.

    It is not the idea or approach that is at fault with jQuery and several
    other libraries, it is their implementation (particularly here: using
    error-prone browser sniffing without apparent need). And for the most part
    *that* is what is generally frowned upon here.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Jul 25, 2008
    #6
  7. Aaron Gray

    Aaron Gray Guest

    "Thomas 'PointedEars' Lahn" <> wrote in message
    news:...
    > Aaron Gray wrote:
    >> "Henry" <> wrote:
    >>> On Jul 25, 3:41 pm, Aaron Gray wrote:
    >>>> There does not seem too be anyway to test if two jQuery
    >>>> references are the same element.
    >>>>
    >>>> Given :-
    >>>>
    >>>> ... <div id="1"></div> ....
    >>>>
    >>>> Then :-
    >>>>
    >>>> alert( $("#1") == $("#1"))
    >>>>
    >>>> return false.
    >>> As would be expected because each JQuery request creates a new object
    >>> to wrap the result, and so each will be distinct from all others in
    >>> terms of identity.

    >>
    >> Yes, and no way to overload the '==' operator in Javascript, unlike in
    >> C++.

    >
    > However, the jQuery object in question might provide a property or method
    > to
    > return the target element object of each wrapped object; a good API would.
    > Then the property values or the return values of these method calls could
    > be
    > compared as if no wrapper object was present.
    >
    > Despite jQuery's provably bad code quality, as the beginner that you are
    > you
    > should be very slow to attribute things not being possible to anything
    > else
    > but your own lack of experience.


    I have read jQuery's source and am not exactly a beginner Thomas.

    A simple comparison function should have been provided by the author to me
    this show just how much it has been thought about in the first place,
    judging by the code.

    In my book there are levels of completeness to API's in general. This is
    particularaly true of API's in languages like C++ and Java which is where I
    come from.

    Aaron
    Aaron Gray, Jul 25, 2008
    #7
  8. Thomas 'PointedEars' Lahn wrote:
    > Aaron Gray wrote:
    >> "Henry" <> wrote:
    >>> On Jul 25, 3:41 pm, Aaron Gray wrote:
    >>>> There does not seem too be anyway to test if two jQuery
    >>>> references are the same element.
    >>>>
    >>>> Given :-
    >>>>
    >>>> ... <div id="1"></div> ....
    >>>>
    >>>> Then :-
    >>>>
    >>>> alert( $("#1") == $("#1"))
    >>>>
    >>>> return false.
    >>> As would be expected because each JQuery request creates a new object
    >>> to wrap the result, and so each will be distinct from all others in
    >>> terms of identity.

    >> Yes, and no way to overload the '==' operator in Javascript, unlike in C++.

    >
    > However, the jQuery object in question might provide a property or method to
    > return the target element object of each wrapped object; a good API would.
    > Then the property values or the return values of these method calls could be
    > compared as if no wrapper object was present.


    And there it is, as hinted by friend Firebug :)

    // "true"
    window.alert($("#a1")[0] == $("#a1")[0]);

    When passed a string expression, jQuery's $() method returns a kind of
    augmented collection[1] of element objects for matching elements. Quite
    obviously, when one attempts to match by ID which must be unique throughout
    a Valid document, the first and only item of that collection is the
    reference to the target element object.

    It should be noted, though, that we are dealing with host objects here, and
    therefore the equals operation does not need to work like with native
    objects. (Nevertheless, no hard proof has been provided yet of an
    implementation showing different behavior.)

    > Despite jQuery's provably bad code quality, as the beginner that you are you
    > should be very slow to attribute things not being possible to anything else
    > but your own lack of experience.


    q.e.d.


    PointedEars
    ___________
    [1] for the lack of a better word
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
    Thomas 'PointedEars' Lahn, Jul 25, 2008
    #8
  9. Aaron Gray wrote:
    > "Thomas 'PointedEars' Lahn" <> wrote in message
    > news:...
    >> Aaron Gray wrote:
    >>> "Henry" <> wrote:
    >>>> On Jul 25, 3:41 pm, Aaron Gray wrote:
    >>>>> There does not seem too be anyway to test if two jQuery
    >>>>> references are the same element.
    >>>> [...]
    >>> Yes, and no way to overload the '==' operator in Javascript, unlike in
    >>> C++.

    >> However, the jQuery object in question might provide a property or method
    >> to
    >> return the target element object of each wrapped object; a good API would.
    >> Then the property values or the return values of these method calls could
    >> be
    >> compared as if no wrapper object was present.
    >>
    >> Despite jQuery's provably bad code quality, as the beginner that you are
    >> you
    >> should be very slow to attribute things not being possible to anything
    >> else
    >> but your own lack of experience.


    Your quoting sucks big time. Get an application that deserves to be called
    newsreader. Probably someone has told you this before.

    > I have read jQuery's source and am not exactly a beginner Thomas.


    As for me, you qualify as a beginner with ECMAScript implementations if you
    are unable to find the `0' property of a user-defined object.

    > A simple comparison function should have been provided by the author to me
    > this show just how much it has been thought about in the first place,
    > judging by the code.


    See my supplemental.

    > In my book there are levels of completeness to API's in general. This is
    > particularaly true of API's in languages like C++ and Java which is where I
    > come from.


    Much you have yet to learn, young apprentice.[tm]


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
    Thomas 'PointedEars' Lahn, Jul 25, 2008
    #9
  10. Aaron Gray

    Aaron Gray Guest

    "Thomas 'PointedEars' Lahn" <> wrote in message
    news:...
    > Thomas 'PointedEars' Lahn wrote:
    >> Aaron Gray wrote:
    >>> "Henry" <> wrote:
    >>>> On Jul 25, 3:41 pm, Aaron Gray wrote:
    >>>>> There does not seem too be anyway to test if two jQuery
    >>>>> references are the same element.
    >>>>>
    >>>>> Given :-
    >>>>>
    >>>>> ... <div id="1"></div> ....
    >>>>>
    >>>>> Then :-
    >>>>>
    >>>>> alert( $("#1") == $("#1"))
    >>>>>
    >>>>> return false.
    >>>> As would be expected because each JQuery request creates a new object
    >>>> to wrap the result, and so each will be distinct from all others in
    >>>> terms of identity.
    >>> Yes, and no way to overload the '==' operator in Javascript, unlike in
    >>> C++.

    >>
    >> However, the jQuery object in question might provide a property or method
    >> to
    >> return the target element object of each wrapped object; a good API
    >> would.
    >> Then the property values or the return values of these method calls could
    >> be
    >> compared as if no wrapper object was present.

    >
    > And there it is, as hinted by friend Firebug :)
    >
    > // "true"
    > window.alert($("#a1")[0] == $("#a1")[0]);


    Ah, I'll eat my hat :)

    Not very neat or very obvious. Don't like that kind of code as it is not
    easy readable by beginner, novice, or part timer.

    Still think it should provide a compare method, no reason not to.

    > When passed a string expression, jQuery's $() method returns a kind of
    > augmented collection[1] of element objects for matching elements. Quite
    > obviously, when one attempts to match by ID which must be unique
    > throughout
    > a Valid document, the first and only item of that collection is the
    > reference to the target element object.


    Yes I did notice this but only half took it in, and did not follow it up on
    needing the comparison operation.

    > It should be noted, though, that we are dealing with host objects here,
    > and
    > therefore the equals operation does not need to work like with native
    > objects. (Nevertheless, no hard proof has been provided yet of an
    > implementation showing different behavior.)
    >
    >> Despite jQuery's provably bad code quality, as the beginner that you are
    >> you
    >> should be very slow to attribute things not being possible to anything
    >> else
    >> but your own lack of experience.


    It was not obvious and obvious things should always be easy in libraries in
    my book. The less brain space I use using a library the more brain space I
    have to dealing with the problem domain that I am providing a solution to.

    Anyway I have part read 262 twice, its not easy digestable, have been
    meaning to put in a full time reading at some point :)

    Cheers Thomas,

    Aaron
    Aaron Gray, Jul 25, 2008
    #10
  11. Aaron Gray

    dhtml Guest

    On Jul 25, 3:48 pm, "Aaron Gray" <> wrote:
    > "Thomas 'PointedEars' Lahn" <> wrote in messagenews:...
    >
    >
    > > therefore the equals operation does not need to work like with native
    > > objects.  (Nevertheless, no hard proof has been provided yet of an
    > > implementation showing different behavior.)

    >


    How about the window object in MSIE?

    <script>
    window.foo = function() { alert([this.document == window.document,
    this == window]); };
    foo();
    </script>

    IE: alert "true, false"
    All other browsers would alert "true, true"

    Though it is likely that the unexpected result is caused by the
    identity of "window" and "this" being different (a "cloned" window)
    and probably not bug of the equals operator.

    > Anyway I have part read 262 twice, its not easy digestable,


    That is true.
    Other specifications that are useful are the DOM specs, CSS2.1, and
    HTML 4.01


    > have been
    > meaning to put in a full time reading at some point :)
    >


    It's not a great sit-down read-through.

    Some parts that might seem more relevant and easier to digest:
    Execution COntexts, Scope Chain and identifier Resolution, the built
    in types (Array, et c), and the operators parts are useful and not as
    hard t understand.

    The reference for things like "Array.prototype.unshift" method are
    useful.

    Garrett

    > Cheers Thomas,
    >
    > Aaron
    dhtml, Jul 26, 2008
    #11
  12. dhtml wrote:
    > On Jul 25, 3:48 pm, "Aaron Gray" <> wrote:
    >> "Thomas 'PointedEars' Lahn" <> wrote:
    >>> therefore the equals operation does not need to work like with native
    >>> objects. (Nevertheless, no hard proof has been provided yet of an
    >>> implementation showing different behavior.)

    >
    > How about the window object in MSIE?


    Maybe you should search the archives before you post an argument.

    > <script>
    > window.foo = function() { alert([this.document == window.document,
    > this == window]); };
    > foo();
    > </script>
    >
    > IE: alert "true, false"
    > All other browsers would alert "true, true"


    This is exactly the lack of hard proof that I was talking about.

    > Though it is likely that the unexpected result is caused by the
    > identity of "window" and "this" being different (a "cloned" window)
    > and probably not bug of the equals operator.


    I did not suggest the cause of a perceived inequality was a bug. In fact,
    the behavior observed here is standards compliant regarding the equals
    operation.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Jul 26, 2008
    #12
  13. Aaron Gray

    dhtml Guest

    On Jul 25, 6:17 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > dhtml wrote:
    > > On Jul 25, 3:48 pm, "Aaron Gray" <> wrote:
    > >> "Thomas 'PointedEars' Lahn" <> wrote:

    > > How about the window object in MSIE?

    >
    > Maybe you should search the archives before you post an argument.
    >


    http://groups.google.com/group/comp...=window reference msie&qt_g=Search this group

    ?

    Maybe you should post up a relevant link.

    > I did not suggest the cause of a perceived inequality was a bug.  In fact,
    > the behavior observed here is standards compliant regarding the equals
    > operation.
    >


    Only if it can it be proven that there are two different window
    references. How can it be proven?

    Garrett

    > PointedEars
    dhtml, Jul 26, 2008
    #13
  14. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> dhtml wrote:
    >>> On Jul 25, 3:48 pm, "Aaron Gray" <> wrote:
    >>>> "Thomas 'PointedEars' Lahn" <> wrote:
    >>> How about the window object in MSIE?

    >> Maybe you should search the archives before you post an argument.

    >
    > http://groups.google.com/group/comp...=window reference msie&qt_g=Search this group
    >
    > ?
    >
    > Maybe you should post up a relevant link.


    Maybe you should learn how to search using appropriate keywords.

    >> I did not suggest the cause of a perceived inequality was a bug. In fact,
    >> the behavior observed here is standards compliant regarding the equals
    >> operation.

    >
    > Only if it can it be proven that there are two different window
    > references. How can it be proven?


    I do not think it can, but you miss the point. In your test case you have
    assigned a Function object reference to the `foo' property of the object
    referred to by the `window' property of an object in the scope chain. Then
    you call a foo() function as the method of an object in the scope chain.

    It is not logical to assume that you would be calling the same method on the
    same object, and it is therefore not logical to assume that `window' and
    `this' in the method's local execution context refer to the same object.
    And as we are dealing with host objects here, it would also appear not to be
    possible to determine (this way) whether or not the perceived inequality is
    an indication of an actual non-identity.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
    Thomas 'PointedEars' Lahn, Jul 26, 2008
    #14
  15. Aaron Gray

    dhtml Guest

    On Jul 25, 7:25 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > dhtml wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> dhtml wrote:
    > >>> On Jul 25, 3:48 pm, "Aaron Gray" <> wrote:
    > >>>> "Thomas 'PointedEars' Lahn" <> wrote:
    > >>> How about the window object in MSIE?
    > >> Maybe you should search the archives before you post an argument.

    >
    > >http://groups.google.com/group/comp.lang.javascript/search?group=comp....

    >
    > > ?

    >
    > > Maybe you should post up a relevant link.

    >
    > Maybe you should learn how to search using appropriate keywords.


    Please enlighten the group by showing us how. I would like to see the
    right keywords showing the relevant document, near the top of the
    search result, where the relevant document provides the answer.

    That would be a great way to get right down to the heart of the
    matter.


    > >> I did not suggest the cause of a perceived inequality was a bug.  Infact,
    > >> the behavior observed here is standards compliant regarding the equals
    > >> operation.

    >
    > > Only if it can it be proven that there are two different window
    > > references. How can it be proven?

    >
    > I do not think it can, but you miss the point.  In your test case you have
    > assigned a Function object reference to the `foo' property of the object
    > referred to by the `window' property of an object in the scope chain.  


    The identifier "window" should be the same object as the thisArg,
    regardless. Where the object is found in the scope chain would not
    matter (at least in terms of the expected behavior for the language).

    > Then
    > you call a foo() function as the method of an object in the scope chain.
    >
    > It is not logical to assume that you would be calling the same method on the
    > same object, and it is therefore not logical to assume that `window' and
    > `this' in the method's local execution context refer to the same object.


    The window property of the global object is the global object itself.

    If the - this - value is not the global object, then what is - this -?

    Calling the foo method with call() or apply results in the expected
    behavior:-

    foo.call(null);
    foo.call((function(){return this;})());
    foo.call(window);
    foo.apply((function(){return eval('this');})());
    foo.call(eval('window'));
    foo.call((function(){var window;return window;})()); // undefined
    foo.apply((function(){
    return eval('(function(){return this;})();');
    })());
    "true, true"

    The thisArg is always the global object.

    > And as we are dealing with host objects here, it would also appear not tobe
    > possible to determine (this way) whether or not the perceived inequality is
    > an indication of an actual non-identity.
    >


    So it seems to be one of the following:
    1) == operator has special behavior with the window/global object in
    JScript, for which further explanation is warrented, or
    2) the window object is recreated in the execution of a function call.

    1 - An undesirable behavior; possibly a bug (as in "unintended,
    undesiarable behavior", not "spec violation")
    2 - A violation of the spec

    Garrett

    > PointedEars
    dhtml, Jul 26, 2008
    #15
  16. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> dhtml wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> I did not suggest the cause of a perceived inequality was a bug.
    >>>> In fact, the behavior observed here is standards compliant
    >>>> regarding the equals operation.
    >>> Only if it can it be proven that there are two different window
    >>> references. How can it be proven?

    >> I do not think it can, but you miss the point. In your test case you
    >> have assigned a Function object reference to the `foo' property of the
    >> object referred to by the `window' property of an object in the scope
    >> chain.

    >
    > The identifier "window" should be the same object as the thisArg,
    > regardless. Where the object is found in the scope chain would not matter
    > (at least in terms of the expected behavior for the language).


    There is no public standard to back up your claims.

    >> Then you call a foo() function as the method of an object in the scope
    >> chain.
    >>
    >> It is not logical to assume that you would be calling the same method
    >> on the same object, and it is therefore not logical to assume that
    >> `window' and `this' in the method's local execution context refer to
    >> the same object.

    >
    > The window property of the global object is the global object itself.


    There is no public standard to back up your claims.

    > If the - this - value is not the global object, then what is - this -?


    It could be the Global Object which were a different object than the one
    referred to with `window'.

    > Calling the foo method with call() or apply results in the expected
    > behavior:-
    >
    > foo.call(null);
    > foo.call((function(){return this;})());
    > foo.call(window);
    > foo.apply((function(){return eval('this');})());
    > foo.call(eval('window'));
    > foo.call((function(){var window;return window;})()); // undefined
    > foo.apply((function(){ return eval('(function(){return this;})();'); })());
    > "true, true"
    >
    > The thisArg is always the global object.


    You cannot be sure.

    >> And as we are dealing with host objects here, it would also appear not
    >> to be possible to determine (this way) whether or not the perceived
    >> inequality is an indication of an actual non-identity.

    >
    > So it seems to be one of the following: 1) == operator has special
    > behavior with the window/global object in JScript, for which further
    > explanation is warrented, or 2) the window object is recreated in the
    > execution of a function call.
    >
    > 1 - An undesirable behavior; possibly a bug (as in "unintended,
    > undesiarable behavior", not "spec violation")
    > 2 - A violation of the spec


    3 - a standards compliant deviation from your unfounded expectations.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Jul 26, 2008
    #16
  17. Aaron Gray

    dhtml Guest

    On Jul 26, 4:01 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > dhtml wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> dhtml wrote:
    > >>> Thomas 'PointedEars' Lahn wrote:

    > > The identifier "window" should be the same object as the thisArg,
    > > regardless. Where the object is found in the scope chain would not matter
    > > (at least in terms of the expected behavior for the language).

    >
    > There is no public standard to back up your claims.
    >


    The Ecma-262 spec, Entering An Execution Context, for Function Code.

    | 10.2.3 Function Code
    ...
    | The caller provides the this value.


    | 10.1.7 This
    | There is a this value associated with every active execution
    context.
    | The this value depends on the caller

    > >> Then you call a foo() function as the method of an object in the scope
    > >> chain.

    >
    > >> It is not logical to assume that you would be calling the same method
    > >> on the same object, and it is therefore not logical to assume that
    > >> `window' and `this' in the method's local execution context refer to
    > >> the same object.

    >
    > > The window property of the global object is the global object itself.

    >
    > There is no public standard to back up your claims.
    >


    The Ecma-262 spec, again.

    | 10.1.5 Global Object
    | There is a unique global object (15.1), which is created
    | before control enters any execution context.
    ...
    | in the HTML document object model the window property of
    | the global object is the global object itself.
    http://bclary.com/2004/11/07/#a-10.2.3


    > > If the - this - value is not the global object, then what is - this -?

    >
    > It could be the Global Object which were a different object than the one
    > referred to with `window'.
    >


    window is the global object.

    > > Calling the foo method with call() or apply results in the expected
    > > behavior:-

    >
    > > foo.call(null);
    > > foo.call((function(){return this;})());
    > > foo.call(window);
    > > foo.apply((function(){return eval('this');})());
    > > foo.call(eval('window'));
    > > foo.call((function(){var window;return window;})()); // undefined
    > > foo.apply((function(){ return eval('(function(){return this;})();'); })());
    > > "true, true"

    >
    > > The thisArg is always the global object.

    >
    > You cannot be sure.


    In all of the above, the thisArg will be the global object. For some
    cases, it will be due to the fact that call() or apply with the first
    argument being null or undefined, the global object will be the this
    arg. In the third case, the window alias is passed in as the thisArg:-
    foo.call(window);

    | 15.3.4.4 Function.prototype.call
    | The call method takes one or more arguments, thisArg and
    | (optionally) arg1, arg2 etc, and performs a function call
    | using the [[Call]] property of the object. If the object does
    | not have a [[Call]] property, a TypeError exception is thrown.
    | The called function is passed arg1, arg2, etc. as the arguments.
    |
    | If thisArg is null or undefined, the called function is passed
    | the global object as the this value.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Lets look at how [[Call]] works.

    | 13.2.1 [[Call]]
    | When the [[Call]] property for a Function object F is called,
    | the following steps are taken:

    | 1. Establish a new execution context using F's FormalParameterList,
    | the passed arguments list, and the this value as described in
    10.2.3.

    f.call is resolved on Function.prototype. Function.prototype.call is
    called with the thisArg as foo. call() performs a function call using
    foo's [[Call]] property and using the global object as the thisArg.

    >
    > > So it seems to be one of the following: 1) == operator has special
    > > behavior with the window/global object in JScript, for which further
    > > explanation is warrented, or 2) the window object is recreated in the
    > > execution of a function call.

    >
    > > 1 - An undesirable behavior; possibly a bug (as in "unintended,
    > > undesiarable behavior", not "spec violation")
    > > 2 - A violation of the spec

    >
    > 3 - a standards compliant deviation from your unfounded expectations.
    >


    It is not exactly clear what is going on with the window vs the
    thisArg of a function executing in global context. There is no reason
    to believe that this is standards compliant.


    Garrett

    > PointedEars
    dhtml, Jul 26, 2008
    #17
  18. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> dhtml wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> dhtml wrote:
    >>>>> Thomas 'PointedEars' Lahn wrote:
    >>> The identifier "window" should be the same object as the thisArg,
    >>> regardless. Where the object is found in the scope chain would not matter
    >>> (at least in terms of the expected behavior for the language).

    >> There is no public standard to back up your claims.

    >
    > The Ecma-262 spec, Entering An Execution Context, for Function Code.
    >
    > | 10.2.3 Function Code
    > ...
    > | The caller provides the this value.
    >
    >
    > | 10.1.7 This
    > | There is a this value associated with every active execution
    > context.
    > | The this value depends on the caller


    Yes, on the caller. You assume the caller to be the same object that you
    assigned the property to, but there is no requirement for that.

    >>>> Then you call a foo() function as the method of an object in the scope
    >>>> chain.
    >>>> It is not logical to assume that you would be calling the same method
    >>>> on the same object, and it is therefore not logical to assume that
    >>>> `window' and `this' in the method's local execution context refer to
    >>>> the same object.
    >>> The window property of the global object is the global object itself.

    >> There is no public standard to back up your claims.

    >
    > The Ecma-262 spec, again.
    >
    > | 10.1.5 Global Object
    > | There is a unique global object (15.1), which is created
    > | before control enters any execution context.
    > ...
    > | in the HTML document object model the window property of
    > | the global object is the global object itself.
    > http://bclary.com/2004/11/07/#a-10.2.3


    Examples are not normative. Besides, you are not citing an authoritative
    source; I do not even need to visit the site to know that.

    >>> If the - this - value is not the global object, then what is - this -?

    >> It could be the Global Object which were a different object than the one
    >> referred to with `window'.

    >
    > window is the global object.


    You are mistaken.

    >>> Calling the foo method with call() or apply results in the expected
    >>> behavior:-
    >>> foo.call(null);
    >>> foo.call((function(){return this;})());
    >>> foo.call(window);
    >>> foo.apply((function(){return eval('this');})());
    >>> foo.call(eval('window'));
    >>> foo.call((function(){var window;return window;})()); // undefined
    >>> foo.apply((function(){ return eval('(function(){return this;})();'); })());
    >>> "true, true"
    >>> The thisArg is always the global object.

    >> You cannot be sure.

    >
    > In all of the above, the thisArg will be the global object.


    Again, that is your assumption. As you are unable to see or do not want to
    see the other possibilities explaining the outcome of your test case, it
    would appear to be best to end this discussion now.

    > [...]
    > Lets look at how [[Call]] works.


    We are dealing with a scope chain, which items we do not know for sure, and
    host objects here.

    >>> So it seems to be one of the following: 1) == operator has special
    >>> behavior with the window/global object in JScript, for which further
    >>> explanation is warrented, or 2) the window object is recreated in the
    >>> execution of a function call.
    >>> 1 - An undesirable behavior; possibly a bug (as in "unintended,
    >>> undesiarable behavior", not "spec violation")
    >>> 2 - A violation of the spec

    >> 3 - a standards compliant deviation from your unfounded expectations.

    >
    > It is not exactly clear what is going on with the window vs the
    > thisArg of a function executing in global context. There is no reason
    > to believe that this is standards compliant.


    Yes, there is.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Jul 26, 2008
    #18
  19. Aaron Gray

    dhtml Guest

    On Jul 26, 12:32 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > dhtml wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> dhtml wrote:
    > >>> Thomas 'PointedEars' Lahn wrote:
    > >>>> dhtml wrote:
    > >>>>> Thomas 'PointedEars' Lahn wrote:
    > >>> The identifier "window" should be the same object as the thisArg,
    > >>> regardless. Where the object is found in the scope chain would not matter
    > >>> (at least in terms of the expected behavior for the language).
    > >> There is no public standard to back up your claims.

    >
    > > The Ecma-262 spec, Entering An Execution Context, for Function Code.

    >
    > > | 10.2.3 Function Code
    > > ...
    > > | The caller provides the this value.

    >
    > > | 10.1.7 This
    > > | There is a this value associated with every active execution
    > > context.
    > > | The this value depends on the caller

    >
    > Yes, on the caller.  You assume the caller to be the same object that you
    > assigned the property to, but there is no requirement for that.
    >
    >
    >
    > >>>> Then you call a foo() function as the method of an object in the scope
    > >>>> chain.
    > >>>> It is not logical to assume that you would be calling the same method
    > >>>> on the same object, and it is therefore not logical to assume that
    > >>>> `window' and `this' in the method's local execution context refer to
    > >>>> the same object.
    > >>> The window property of the global object is the global object itself.
    > >> There is no public standard to back up your claims.

    >
    > > The Ecma-262 spec, again.

    >
    > > | 10.1.5 Global Object
    > > | There is a unique global object (15.1), which is created
    > > | before control enters any execution context.
    > > ...
    > > | in the HTML document object model the window property of
    > > | the global object is the global object itself.
    > >http://bclary.com/2004/11/07/#a-10.2.3

    >
    > Examples are not normative.  Besides, you are not citing an authoritative
    > source; I do not even need to visit the site to know that.
    >


    Not normative? I posted text that comes directly from the official
    Ecma-262 spec. What's wrong with that?

    Since the spec is in PDF, I put up a link to Bob Clary's HTML Edition.
    It is directly relevant to this discussion (that you seem to be trying
    to destroy) and it makes it easy for anyone to click on that link and
    go directly to the section.

    I don't have a problem with that link.

    > >>> If the - this - value is not the global object, then what is - this -?
    > >> It could be the Global Object which were a different object than the one
    > >> referred to with `window'.

    >
    > > window is the global object.

    >
    > You are mistaken.
    >


    According to the citation from the Ecma-262 spec, window is the global
    object.

    > >>> Calling the foo method with call() or apply results in the expected
    > >>> behavior:-
    > >>> foo.call(null);
    > >>> foo.call((function(){return this;})());
    > >>> foo.call(window);
    > >>> foo.apply((function(){return eval('this');})());
    > >>> foo.call(eval('window'));
    > >>> foo.call((function(){var window;return window;})()); // undefined
    > >>> foo.apply((function(){ return eval('(function(){return this;})();'); })());
    > >>> "true, true"
    > >>> The thisArg is always the global object.
    > >> You cannot be sure.

    >
    > > In all of the above, the thisArg will be the global object.

    >
    > Again, that is your assumption.


    It is the expected behavior based on the Ecma 262 spec for the exact
    reasons I provided.

    > As you are unable to see or do not want to
    > see the other possibilities explaining the outcome of your test case, it
    > would appear to be best to end this discussion now.
    >


    What other possibilities?

    Such senseless rebuttal gives the impression that you are desperate to
    "win" the argument. I don't see this with any other poster. The
    discussion doesn't need to be ended. In fact, what would seem to be
    the most benefit at this point would be some insight on what MSIE is
    doing with the thisArg in a global method call.

    There is no more benefit of "end the discussion now" than your earlier
    post chiding "search the archives" and follow up of rebuking me "learn
    how to search using appropriate keywords" and then providing
    absolutely no example of such a search result with a relevant post.

    Just search the archives for the any of the statement: "score
    adjusted" and find a plethora of such posts.


    > > [...]
    > > Lets look at how [[Call]] works.

    >
    > We are dealing with a scope chain, which items we do not know for sure, and
    > host objects here.
    >


    What items? Are you suggesting that there is a window property added
    to the activation object in the call to foo?

    If you are suggesting some form of shadowing, then you have provided
    no evidence for that.

    There is a - this - argument that is the global object.
    There is a window object that is also the global object.

    How can you distinguish that these objects are different?

    I have already demonstrated that this.document == window.document. We
    could take this further and explore the properties of the this object
    and those of the window object:

    <script type="text/javascript">
    var fooVar = 1;

    window.foo = function(p, g1, g2) {
    if(!g1) g1 = this;
    if(!g2) g2 = window;
    alert(g1[p] !== g2[p] ? "different" : "same");
    };

    foo("Array");
    foo("fooVar");

    // foo("Array", this, top);
    // foo("fooVar", self, top);
    </script>

    If we can get a 'different' result, then that would show that this and
    global are different. Thomas, can you provide a value for - p - where
    the result of calling the foo function will result in "different"?
    That would back your claim up.

    I am not able to observe a difference between the global object and
    the window object. Only the Equals and Strict Equals operators.

    <script>
    alert([
    this === top,
    window === top,
    this === window,
    ,'\n',
    this === self,
    window === self,
    self === top,
    ]);
    </script>

    So far, you have provided no evidence that window and global are
    different objects.

    > >>> So it seems to be one of the following: 1) == operator has special
    > >>> behavior with the window/global object in JScript, for which further
    > >>> explanation is warrented, or 2) the window object is recreated in the
    > >>> execution of a function call.
    > >>> 1 - An undesirable behavior; possibly a bug (as in "unintended,
    > >>> undesiarable behavior", not "spec violation")
    > >>> 2 - A violation of the spec
    > >> 3 - a standards compliant deviation from your unfounded expectations.

    >
    > > It is not exactly clear what is going on with the window vs the
    > > thisArg of a function executing in global context. There is no reason
    > > to believe that this is standards compliant.

    >
    > Yes, there is.
    >


    If it is exactly clear what is going on, then it has not been
    demonstrated. Since it is your claim that it is, it is up to you to
    provide evidence for this claim.

    Garrett

    > PointedEars
    dhtml, Jul 27, 2008
    #19
  20. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> dhtml wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> dhtml wrote:
    >>>>> Thomas 'PointedEars' Lahn wrote:
    >>>>>> Then you call a foo() function as the method of an object in the scope
    >>>>>> chain.
    >>>>>> It is not logical to assume that you would be calling the same method
    >>>>>> on the same object, and it is therefore not logical to assume that
    >>>>>> `window' and `this' in the method's local execution context refer to
    >>>>>> the same object.
    >>>>> The window property of the global object is the global object itself.
    >>>> There is no public standard to back up your claims.
    >>> The Ecma-262 spec, again.
    >>> | 10.1.5 Global Object
    >>> | There is a unique global object (15.1), which is created
    >>> | before control enters any execution context.
    >>> ...
    >>> | in the HTML document object model the window property of
    >>> | the global object is the global object itself.
    >>> http://bclary.com/2004/11/07/#a-10.2.3

    >> Examples are not normative. Besides, you are not citing an authoritative
    >> source; I do not even need to visit the site to know that.

    >
    > Not normative?


    Examples (in specifications) are never normative.

    > I posted text that comes directly from the official
    > Ecma-262 spec. What's wrong with that?


    You have quoted it out of context:

    | 10.1.5 Global Object
    |
    | There is a unique global object (section 15.1), which is created before
    | control enters any execution context. Initially the global object has the
    | following properties:
    |
    | • Built-in objects such as Math, String, Date, parseInt, etc. These have
    | attributes { DontEnum }.
    | • Additional host defined properties. This may include a property whose
    | value is the global object itself; for example, in the HTML document
    | object model the window property of the global object is the global
    | object itself.

    Note the MAY; it indicates a possibility, not a requirement. Obviously, to
    define "the HTML document object model", however that is to be understood
    (since there are several such models), is well beyond the scope of this
    Specification.

    And incidentally, this part of the Specification is less precisely worded
    than its normative parts; for example, one can read there "is the global
    object itself" instead of the proper "is a reference to the global object
    itself."

    We have been over this before. You have already been recommended to read
    previous discussions on this matter before. Your failure to comply and your
    bringing it up again instead marks you as an ignorant.

    > Since the spec is in PDF, I put up a link to Bob Clary's HTML Edition.
    > It is directly relevant to this discussion (that you seem to be trying
    > to destroy) and it makes it easy for anyone to click on that link and
    > go directly to the section.
    >
    > I don't have a problem with that link.


    That figures. The PDF and hardcopy versions are the only normative versions
    of the ECMAScript Specification.

    >>>>> Calling the foo method with call() or apply results in the expected
    >>>>> behavior:-
    >>>>> foo.call(null);
    >>>>> foo.call((function(){return this;})());
    >>>>> foo.call(window);
    >>>>> foo.apply((function(){return eval('this');})());
    >>>>> foo.call(eval('window'));
    >>>>> foo.call((function(){var window;return window;})()); // undefined
    >>>>> foo.apply((function(){ return eval('(function(){return this;})();'); })());
    >>>>> "true, true"
    >>>>> The thisArg is always the global object.
    >>>> You cannot be sure.
    >>> In all of the above, the thisArg will be the global object.

    >> Again, that is your assumption.

    >
    > It is the expected behavior based on the Ecma 262 spec for the exact
    > reasons I provided.


    It is not.

    >> As you are unable to see or do not want to
    >> see the other possibilities explaining the outcome of your test case, it
    >> would appear to be best to end this discussion now.

    >
    > What other possibilities?


    Such possibilities like that the augmentation of a host object might cause
    the augmentation of the Global Object, for example, as the former's [[Set]]
    method may be arbitrary implemented as supported by the Specification.

    > Such senseless rebuttal gives the impression that you are desperate to
    > "win" the argument. [...]


    Of course, to those who refuse to think about it, the rebuttal must seem
    senseless. To others, it might appear as an attempt to save one's strength
    for less futile arguments than this.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Jul 27, 2008
    #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. Roger Leigh
    Replies:
    8
    Views:
    414
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Replies:
    3
    Views:
    434
    Victor Bazarov
    Nov 10, 2004
  3. DanielEKFA
    Replies:
    8
    Views:
    586
    DanielEKFA
    May 16, 2005
  4. Replies:
    3
    Views:
    3,402
  5. lorlarz
    Replies:
    6
    Views:
    207
    David Mark
    Mar 25, 2010
Loading...

Share This Page