I agree with Ariel, that this would be better served as a static method. Dojo does the (fn, scope) (actually, we do a mixmatch and allow curried args, but I digress) and it definitely is a learning curve for js n00bs, and certainly not very jQuery-ish. by making it a separate method, it becomes entirely opt-in for power users and is nearly as concise as the proposed further overloading of the existing signature.
I ported dojo's .hitch(), which is likely more in line with Ariel's statement. http://higginsforpresident.net/js/jq.hitch.js My $0.02US Regards, Peter On Mon, May 4, 2009 at 3:56 PM, Brandon Aaron <brandon.aa...@gmail.com> wrote: > I don't agree that this is confusing. I find it to be very beneficial to > have a method signature that grows to meet your needs but doesn't get in > your way when you don't need all of it. I know we've received both insult > and praise for our overloaded methods but that is how we roll! :) > It might be inconsistent for the moment but we can fix that. This has been > an oft-requested feature (even by the jQuery UI team) specifically for > events. Certainly we'll need to review the other places we use a callback > and see if it makes sense to provide an optional alternate scope. I'm all > for the pattern of anywhere we provide a callback, an optional scope should > follow. However, we need to make sure people still have access to the actual > element. > Although just giving everyone a $.bind method is much easier on us, I don't > think it fits very well into the philosophy of do more, write less. I'd also > argue that this would be more of a learning curve to some than the optional > scope param. I'm not adverse to providing both though since we'll most > likely need $.bind if we start adding optional scopes to other methods in > the API. It would be as simple as exposing another jQuery utility method. > Also, I forgot to include the helper methods, like click, in this patch. > These would also need include the ajax event methods and probably the ready > shortcuts. > -- > Brandon Aaron > > On Mon, May 4, 2009 at 7:12 AM, Ariel Flesler <afles...@gmail.com> wrote: >> >> I like it... but I think it is confusing and inconsistent. >> We add this for events, but why not for animations ? or ajax >> requests ? >> >> Also... you need to document, the 'this' of the handler will be the >> currentTarget, UNLESS you passed a scope to bind(). I think features >> like this affect the learning curve and confuse novice users. >> >> As I see it, I'd rather add a static method like $.bind. >> >> $(...).bind("type", $.bind(scope,fn)); >> >> $.bind should copy the guid ($.event.proxy) so that the returned >> function can be unbound using just fn and there's no need to save it >> in a var. >> >> >> My $0.02 >> >> Cheers >> -- >> Ariel Flesler >> On May 4, 1:47 am, Brandon Aaron <brandon.aa...@gmail.com> wrote: >> > Looking for any feedback on #3699 before committing, which is for >> > allowing >> > an alternative scope for events. There is a patch attached to the >> > ticket. >> > The ticket actually proposes a method signature that doesn't really fit >> > jQuery's style. I added a patch that allows the following call signature >> > instead. >> > $(...).bind("type", fn, scope); >> > $(...).bind("type", data, fn, scope); >> > >> > This also applies to .one() and .live(). >> > >> > The patch utilizes the internal event.proxy method with a tweak to >> > include >> > an optional scope. >> > >> > -- >> > Brandon Aaron >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
