I've already sent a ticket about a bug in the jQuery.fn.add method
(#821), but after some more test I'm convincing myself that there is a
general problem in the jQuery implementation.
Apparently, now all or most method change the returned jQuery object
(another example is the show/hide methods). In my opinion this is not a
good idea.
As I pointed out also in the mentioned ticked, it should be a clear
distinction among chainable and non-chainable methods.
Actually, there should be three types of methods:
1) Fully chainable methods (like add, show etc.) which should return the
same object whose method was called
2) Indirectly chainable methods (like find, filter etc.) which should
return a new jQuery object containing a reference to the method owner.
3) Non-chainable methods (like get, attr etc.) which return something
else than a jQuery object
Fully chainable methods should *always* return the method owner object
itself (no clones or other), and other methods should left the method
owner unchanged and return a new object.
While browsing the code, I found some other things that perplexed me. I
can't understand what's the point in creating objects that mimic an
array but lack fundamental properties and methods of the array object.
Watching with firebug, I found objects containing elements retrievable
with the [] operator, but without the length property, and without the
push method (see also the note below). Such practices, I think, could
only be error prone and confusing. Why not simply maintain an array of
object as a property of the jQuery object, avoiding all that tricky code
to simply add or remove an element, or change some property of the
collection? What is the benefit from having a pseudo-array object
instead of a clean collection object with only the add, remove, and get
methods? The possibility to use the [] operator? If there is no other
reason, it's a very small advantage (if it could be considered as an
advantage) in front of a cryptic code and a significant increment of the
risk of errors.
I realize that a change like that could generate severe compatibility
problems, but maybe in future versions the use of the [] operator could
be deprecated and gradually removed (the use of a 'compatibility patch',
like the one distributed for version 1.1 may be a good solution).
A final note:
this is the code of the pushStack and setArray methods:
pushStack: function( a ) {
var ret = jQuery(this);
ret.prevObject = this;
return ret.setArray( a );
},
setArray: function( a ) {
this.length = 0;
[].push.apply( this, a );
return this;
},
pushStack creates a new jQuery object with the same content of this,
than save this object as prevObject, then call setArray to copy the
contents of the array a to the new jQuery object which is finally
returned. Note that setArray sets the length property to 0 but do not
remove the elements, so you can have an object that contains elements
but has zero length. Yes, by applying the push method (but,
incidentally, why to use tricks like [].push.apply(this, a) instead of
"inheriting" the push method?), we override the pseudo-array contents,
but if the object contained more elements than those inserted with push,
we have an inconsistent object with, for example, length=3 and 5
elements. Elements of index 3 and 4 are 'illegal' elements, but can
always be retrieved with the [] operator.
Does not look like a mess, all that? Maybe I'm missing something, but
the push stack method could not be simply something like this?:
pushStack: function( a ) {
var ret = jQuery(a);
ret.prevObject = this;
return ret;
},
I showed this example because I have the impression that the jQuery
implementation needs a accurate cleaning. I suspect, also, that speed
could be significantly increased by removing unnecessary complications.
Ok, thanks for your attention, I hope my remarks could be a contribution
to improve that very useful and well conceived javascript library that
jQuery is.
Regards
Paolo
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
