I actually have to disagree with Pete and Ariel on this.
There are plenty of concepts that throw off the uninitiated, such as
any scoping, or even the funky concept of defining a function in the
method signature of another method.
And since the parameter is the last in the signature, it's completely
transparent to people who don't need it.
The other downside I see to using a static method, besides the fact
that it's harder to read is that doing it that way would create 2
function objects for every event.
What you would have would be:
function(){/*added by static bind*/
function(){ /*proxy*/
eventListener; /*actual method*/
}
}
If you're going to need scope correction, chances are you're not just
including jquery to do some minimal work, but rather building large
applications (and hence, would probably be doing a lot of these calls,
and would be more sensitive to performance).
Brandon, I like your API changes you made to the ticket, and overall,
I think this looks good. I agree that consistency should be kept with
other aspects of the library, but it's not as common, and I don't
think it's important enough to derail this feature.
Thanks for taking a look at it :)
Nate Cavanaugh
Director of User Interface Engineering
Liferay, Inc.
Enterprise. Open Source. For life.
On May 4, 2009, at 7:08 AM, pete higgins wrote:
>
> 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
> <[email protected]> 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 <[email protected]>
>> 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 <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
