That'd be excellent - thanks! --John
On 8/16/07, Andy Matthews <[EMAIL PROTECTED]> wrote: > > John... > > I should have added on to my OP. Better examples are really what is needed, > not changes to the language. Let me read through and see possible RW > examples of eq() or is() and let me say "hey I did that very thing last > week, but with 10 more lines of code)". > > andy > > -----Original Message----- > From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of John Resig > Sent: Thursday, August 16, 2007 1:48 PM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: jQuery negatives: dual/triple/quadruple special-case > uses for both function calls and method names > > > Sure, that makes sense - and it's obviously difficult. I think the burden > may lie on us to write better examples - although, it's hard to think of > ones that aren't complex that also aren't contrived. > > At this point, I look for fringe cases in jQuery where, simply, a plugin is > unable to duplicate functionality (or where a plugin would be hugely > bloated, where the result in core would be quite simple, instead). > > That being said, I'm still advancing the library with some fun methods like > .andSelf() whose uses won't become commonly apparent until far down the > line. > > --John > > On 8/16/07, Andy Matthews <[EMAIL PROTECTED]> wrote: > > > > John... > > > > To be fair...it's very easy to learn the basics of jQuery, but it's > > quite a lot of work and time to learn the really cool stuff. I've > > never used eq() or > > if() and those other because I simply don't understand what they do. > > I'm sure some of them could improve my code dramatically but I don't > > even know WHEN I might use them, so I don't know when to look for > > them. Does that makes sense? > > > > andy > > > > -----Original Message----- > > From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] > > On Behalf Of John Resig > > Sent: Thursday, August 16, 2007 12:53 PM > > To: jquery-en@googlegroups.com > > Subject: [jQuery] Re: jQuery negatives: dual/triple/quadruple > > special-case uses for both function calls and method names > > > > > > I don't understand this argument at all. So this guy is proposing that > > we change all the jQuery methods to: > > > > $Array([array of elems]) > > $Selector("str") > > $HTML("html") > > $Element(DOMElement) > > > > and: > > > > .appendElement(DOMElement) > > .appendHTML("html") > > .appendArray([array of elems]) > > > > what on earth does that gain you? What's the purpose of using a > > language that can overload arguments and not actually using that > > feature? What's the advantage of increasing the size of your API 4-fold? > > > > Incredibly weak argument, obviously someone who's never used the library. > > > > > Some method names make no > > > immediate sense, like .one or .eq, and you can't immediately tell if > > > a method acts on the first element in the collection or all of them. > > > > These arguments are slightly more valid. Although .eq() is going away > > in 1.2. I really don't know what to say, in this case it was simply a > > design decision. We could've had: > > .val() (return nothing, do nothing useful) > > .val("val") (set value) > > .getVal() (get value) > > .getVal("val") (return nothing, do nothing useful) > > > > But why have a state of a method perform nothing useful at all? Why > > not overload it to actually do something? Why double the size of the > > effective API with half-useful functions? > > > > --John > > > > On 8/16/07, Mitch <[EMAIL PROTECTED]> wrote: > > > > > > What do you guys think of this critique of jQuery I found on Simon > > > Willison's site (which is good reading). > > > > > > http://simonwillison.net/2007/Aug/15/jquery/ > > > > > > <quote> > > > jQuery is definitely a popular utility function library, but the > > > sheer amount of dual/triple/quadruple special-case uses for both > > > function calls and method names is an instant turnoff for me. > > > > > > The jQuery object itself can perform a selector query, embed a DOM > > > element, create a DOM element from HTML and assign a DOMContentReady > > > event handler - and probably more. Event handling is separated into > > > separate methods for each event type. Some method names make no > > > immediate sense, like .one or .eq, and you can't immediately tell if > > > a method acts on the first element in the collection or all of them. > > > > > > I can't recommend jQuery to the developers I am mentoring because it > > > is in itself a completely separate abstraction, and a muddy one at > > > that. They will end up having to learn jQuery instead of having to > > > learn DOM, CSS and JS, and when being considered as a direct > > > replacement for those it fails both due to complexity and > > > inconsistency." > > > > > > </quote> > > > > > > Mitch > > > > > > > > > > > > > > >
