@Oleg -

>> Your way is not shorter as this one

It isn't simply about brevity, although that is a concern. My main
goal is to increase the use cases that these methods are able to
account for. In your "as-basic-as-possible" example, it's true that
simply chaining calls to the shorthand methods, i.e. click(), mouseover
(), mouseout() could save a few lines, but ultimately that is trivial.
Also, how would you unbind those handlers if you needed to ("I don't
ever need to" is not really a good enough answer) ? By passing
anonymous functions to bind(), you've lost your ability to clean up
after yourself. I don't really want to get into a debate over personal
coding style, but the fact remains that there are going to be
situations where a group of bound handlers needs to be unbound. So,
for your example, we have to change the actual handlers to named
function references. Then, assuming we have named functions to work
with, your "shorter" answer requires that we again chain the calls to
unbind() (one each per handler). So, your "shorter" solution isn't
shorter unless you give up using unbind(), which is not an option in
my case.

>> and such case, were you need to bind a lot of different events with 
>> different handler to the same element,
>> is not very often. In the most cases you want to bind different events to 
>> different elements.

I respectfully disagree. I'm currently working on large, enterprise
apps and the need to bind multiple handlers to a single element has
arisen frequently. Furthermore, many of the widgets that support
custom events would benefit from being able to dispatch their internal
events at the document level, but that would require that we have a
reasonable way of binding/unbinding multiple events to a single
element. Hence this post :)

>> If you are binding to the same element a lot of events you can also do all 
>> your actions in one
>> handler by checking the e.type.

That's true, but that approach sucks IMO. We could all be doing that
without jQuery. The point (for me) is to encapsulate logic for a given
event on a given element into a single handler.

@Rick - To be honest, I share your concerns about jQuery method names
overlapping with Native methods. But to keep things to the point, my
arguments here are completely unrelated. If we were talking about $
().addEvent/$().removeEvent or $().on()/$().un() I'd have the same
sentiments (my point being that although I understand and agree that
having overlapping method names is unsettling, the fact that they are
arbitrarily named bind() and unbind() for me is moot).

Also, I too considered the potential confusion. One of my main points
in the original comments was that making this change would actually
increase consistency, as $().attr() and $().css() can both accept
either a map of values or an individual key and value. By determining
what was passed, these methods either apply the single key and value
or the entire map. Cheers.


On Sep 5, 8:50 pm, Karl Swedberg <k...@englishrules.com> wrote:
> On Sep 5, 2009, at 6:59 PM, Rick Waldron wrote:
>
> > My concern is mostly the confusion that it will cause with less  
> > experienced developers that are using jQuery... Perhaps I'm just  
> > over thinking the situation.
>
> > I just can't past the thought that bind() and bind() might confuse  
> > some (especially since they do different tasks, unlike indexOf() and  
> > indexOf() that do the same thing but for a string or an array)
>
> > I'm also not really interested in debating something that's just an  
> > opinion.
>
> > Rick
>
> Right on. I'm not all that interested in debating it either. I was  
> mostly hoping to clarify and seeking clarification.
>
> --Karl
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to