On Sep 17, 10:23 am, David Duymelinck <[EMAIL PROTECTED]> wrote:
> But why do you want to use eq/lt/gt as methods if you have them as
> selectors? Can you give an example where a method can do more than a
> selector?
You can do more with a selector in SOME contexts, and only after
converting your data to a string. For me, this is far more intuitive:
$(...).lt(a+b)
than:
$("...:lt("+(a+b)+")")
(For one thing, the extra parens are necessary to avoid a+b concating
as a string.)
Also, the removal of lt/gt() removes a nice symmetry which previously
existed:
$("...:lt(3)") ===> $(...).lt(3)
Now that is:
$("...:lt(3)") ===> $(...).slice(0,3)
Likewise, we used to have:
$("...:gt(3)") ===> $(...).gt(3)
but that's now mutated to:
$("...:gt(3)") ===> $(...).slice(4)
There is no symmetry whatsoever in those, especially because of the
off-by-one of the gt==>slice conversion. Every time i see that, it
makes me cringe.
As a general rule, i find a mini-language (in this case, stringified
selectors) to be more cumbersome to use than the in-language approach
provided by function calls (in this case .lt/gt()). Obviously, though,
opinions differ on this topic. i'm willing to bet, however, that most
long-time programmers will agree with me on this point, and that most
of the people who prefer the selector form are either relatively new
to programming or have JavaScript as their first (or only) programming
language. (That's not meant as an insult, so please don't take it that
way!)
While i agree that slice is a nice addition to jQuery, i strongly
disagree that lt/gt() should be removed in favour of slice. John Resig
argued (in a post last week) that slice is a well-known idiom in
computer science. He's right - it's available as part of the common
Array API in many (but not all) programming languages. The greater/
less-than idiom is a core/built-in part of ALL languages, though, and
so i'll argue that they're easier for people to get a grasp on.
