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]

Re: jQuery Query about comparing jQuery references

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.getEle mentById
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]

Re: jQuery Query about comparing jQuery references

"Henry" <rcornford@rain drop.co.ukwrote in message
news:824a3905-092c-40fc-bd1d-384375d67fb9@h1 7g2000prg.googl egroups.com...

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

[dhtml]

Re: jQuery Query about comparing jQuery references

On Jul 25, 11:08 am, "Aaron Gray" <ang.use...@gma il.comwrote:

"Henry" <rcornf...@rain drop.co.ukwrote in message
>
news:824a3905-092c-40fc-bd1d-384375d67fb9@h1 7g2000prg.googl egroups.com...
>
>
>

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.leng th != result2.length) return false;

Garrett

>
Aaron

[Aaron Gray]

Re: jQuery Query about comparing jQuery references

<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.getEle mentById takes have a page of code with recursion
involved, thats a no go for me.

Aaron

[Thomas 'PointedEars' Lahn]

Re: jQuery Query about comparing jQuery references

Aaron Gray wrote:

"Henry" <rcornford@rain drop.co.ukwrote :

>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.getEle mentById
>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.getEle mentById() 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$8 300dec7@news.de mon.co.uk>

[Aaron Gray]

Re: jQuery Query about comparing jQuery references

"Thomas 'PointedEars' Lahn" <PointedEars@we b.dewrote in message
news:488A3E18.6 0705@PointedEar s.de...

Aaron Gray wrote:

>"Henry" <rcornford@rain drop.co.ukwrote :

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

[Thomas 'PointedEars' Lahn]

Re: jQuery Query about comparing jQuery references

Thomas 'PointedEars' Lahn wrote:

Aaron Gray wrote:

>"Henry" <rcornford@rain drop.co.ukwrote :

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

Re: jQuery Query about comparing jQuery references

Aaron Gray wrote:

"Thomas 'PointedEars' Lahn" <PointedEars@we b.dewrote in message
news:488A3E18.6 0705@PointedEar s.de...

>Aaron Gray wrote:

>>"Henry" <rcornford@rain drop.co.ukwrote :
>>>On Jul 25, 3:41 pm, Aaron Gray wrote:
>>>>There does not seem too be anyway to test if two jQuery
>>>>reference s 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>

[Aaron Gray]

Re: jQuery Query about comparing jQuery references

"Thomas 'PointedEars' Lahn" <PointedEars@we b.dewrote in message
news:488A5161.4 090004@PointedE ars.de...

Thomas 'PointedEars' Lahn wrote:

>Aaron Gray wrote:

>>"Henry" <rcornford@rain drop.co.ukwrote :
>>>On Jul 25, 3:41 pm, Aaron Gray wrote:
>>>>There does not seem too be anyway to test if two jQuery
>>>>reference s 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

[dhtml]

Re: jQuery Query about comparing jQuery references

On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

"Thomas 'PointedEars' Lahn" <PointedE...@we b.dewrote in messagenews:488 A5161.4090004@P ointedEars.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.prototyp e.unshift" method are
useful.

Garrett

Cheers Thomas,
>
Aaron

[Thomas 'PointedEars' Lahn]

Re: jQuery Query about comparing jQuery references

dhtml wrote:

On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

>"Thomas 'PointedEars' Lahn" <PointedE...@we b.dewrote:

>>therefore the equals operation does not need to work like with native
>>objects. (Nevertheless, no hard proof has been provided yet of an
>>implementatio n 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 bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16

[dhtml]

Re: jQuery Query about comparing jQuery references

On Jul 25, 6:17 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

dhtml wrote:

On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

"Thomas 'PointedEars' Lahn" <PointedE...@we b.dewrote:

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.lang.javascript&q=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

[Thomas 'PointedEars' Lahn]

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...@gma il.comwrote:
>>>"Thomas 'PointedEars' Lahn" <PointedE...@we b.dewrote:
>>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.lang.javascript&q=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>

[dhtml]

Re: jQuery Query about comparing jQuery references

On Jul 25, 7:25 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

dhtml wrote:

Thomas 'PointedEars' Lahn wrote:

dhtml wrote:
>On Jul 25, 3:48 pm, "Aaron Gray" <ang.use...@gma il.comwrote:
>>"Thomas 'PointedEars' Lahn" <PointedE...@we b.dewrote:
>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((funct ion(){return this;})());
foo.call(window );
foo.apply((func tion(){return eval('this');}) ());
foo.call(eval(' window'));
foo.call((funct ion(){var window;return window;})()); // undefined
foo.apply((func tion(){
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