jQuery Query about comparing jQuery references

[Aaron Gray]

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

 

[Henry]

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?

 

[Aaron Gray]

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.

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.

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

 

[dhtml]

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


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.



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

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 Gray]

<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

 

[Thomas 'PointedEars' Lahn]

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.

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.

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

 

[Aaron Gray]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Aaron Gray]

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

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

 

[dhtml]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[dhtml]

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

 

[Thomas 'PointedEars' Lahn]

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.

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

 

[dhtml]

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

 

[Thomas 'PointedEars' Lahn]

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

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

 

[dhtml]

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

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

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

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

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

 

[Thomas 'PointedEars' Lahn]

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.

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.

window is the global object.

You are mistaken.

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.

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

 

[dhtml]

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.






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.

You are mistaken.

According to the citation from the Ecma-262 spec, window is 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.

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

 

[Thomas 'PointedEars' Lahn]

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.

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

It is not.

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