jQuery Query about comparing jQuery references - Javascript

This is a discussion on jQuery Query about comparing jQuery references - Javascript ; On Jul 25, 3:48pm, "Aaron Gray" <ang.use...@gmail.com> wrote: > "Thomas 'PointedEars' Lahn" <PointedE...@web.de> wrote in messagenews:488A5161.4090004@PointedEars.de... > > > > therefore the equals operation does not need to work like with native > > objects. (Nevertheless, no hard proof has ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 21

jQuery Query about comparing jQuery references

  1. Default Re: jQuery Query about comparing jQuery references

    On Jul 25, 3:48pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
    > "Thomas 'PointedEars' Lahn" <PointedE...@web.de> wrote in messagenews:488A5161.4090004@PointedEars.de...
    >
    >
    > > 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



  2. Default Re: jQuery Query about comparing jQuery references

    dhtml wrote:
    > On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
    >> "Thomas 'PointedEars' Lahn" <PointedE...@web.de> 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

  3. Default Re: jQuery Query about comparing jQuery references

    On Jul 25, 6:17pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
    wrote:
    > dhtml wrote:
    > > On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
    > >> "Thomas 'PointedEars' Lahn" <PointedE...@web.de> 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....rch+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


  4. Default Re: jQuery Query about comparing jQuery references

    dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> dhtml wrote:
    >>> On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
    >>>> "Thomas 'PointedEars' Lahn" <PointedE...@web.de> 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....rch+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>

  5. Default Re: jQuery Query about comparing jQuery references

    On Jul 25, 7:25pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
    wrote:
    > dhtml wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> dhtml wrote:
    > >>> On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
    > >>>> "Thomas 'PointedEars' Lahn" <PointedE...@web.de> 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....rch?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


  6. Default Re: jQuery Query about comparing jQuery references

    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

  7. Default Re: jQuery Query about comparing jQuery references

    On Jul 26, 4:01am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
    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


  8. Default Re: jQuery Query about comparing jQuery references

    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$8300dec7@news.demon.co.uk>

  9. Default Re: jQuery Query about comparing jQuery references

    On Jul 26, 12:32pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
    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


  10. Default Re: jQuery Query about comparing jQuery references

    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

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast