Urgh, I was typing too fast ;o( Meaning was lost. This is the amended
versio :
On Mar 20, 9:45 am, DBJDBJ <dbj...@gmail.com> wrote:
> The real issue is architecture of jQ. By design jQ object keeps its
> state. State being array of references to dom nodes aka elements.
> The "references" NOT the objects. The pointers. One has to expect that
> anything can happen to the objects which are being referenced.
>
> Example:
> var $1 = $("#sprite") ;
> var $2 = $("#sprite", document.body ) ;
> // at this point $1 and $2 do point to the same element
> $2.remove() ;
> // now where does $1 points to ?
> $1.show()
>
> Think a bit about this : when are two jQ objects equal ?
> They are actually equal when they operate on the same dom objects.
> Which are result of the INITIAL selection STATEMENT.
> Can we have two same sets of dom objects , arrived at with two
> different selectors? Of course we can.
> But does this mean that their two jQ handlers are equal (aka) same
> objects ? No. They are different.
>
> So we have two valid QUESTIONS ON equality of two jQ objects :
>
> Q1 :: Are two jQ objects operating on same DOM elements ?
>
> Q2 :: Are two jQ objects the same ?
>
> Matt has given code to support the answer to the Q1. It is only that
> plugin nAme is deeply troublesome. It should be nameD something like :
> equal_elements
>
> Answer to Q2 is simple :
>
> $("#sprite").selector == $("#sprite").selector // true
>
> And reveals clearly that we have here an very questionable approach.
>
> Q3 :: Why have two jQ objects with same selectors?
> Q4 :: Why have two jQ objects operating on same set of elements ?
>
> I think this might happen only "accidentaly". With dynamicaly created
> elements, or simillar ?
> Also I can imagine one wishing to have some "globar manager of jQ
> instances on the page" ... Where one would like to manage (keep) one
> instance per one set of elements ... I think they would be an overkill
> for scripting of web application client side ? A factory of jQ
> instances anyone ;o)
