Personally I use it through out my code, I lean towards event driven architecture and use the event facilities quite allot.. Cant say I have invested allot of time when looking for alternatives to bindWtihEvent but they are all messier then simple bindWithEvent(this, param)..
On Wed, Feb 9, 2011 at 9:10 AM, Steve Onnis <[email protected]> wrote: > So how are you handling that now in 1.3 for those things (tips and > sortables) if it isn’t in the core? Are you adding it into the class > libraries for those bits of functionality? Or are you doing it a different > way? > > > > *From:* Aaron Newton [mailto:[email protected]] > *Sent:* Wednesday, 9 February 2011 5:52 PM > *To:* [email protected] > *Subject:* Re: [Moo] Re: BindWithEvent deprecated? > > > > Steve, whether or not I agree with you - that bindWithEvent is useful or > not - isn't really the point. bindWithEvent is something that's fairly > rarely used - in the entire MooTools 1.2 codebase, including MooTools More, > it's used twice (tips and sortables). MooTools Core is designed to be as > lean as possible and provide you the tools to build whatever you want. > > > > The fact that you can write a method for yourself to do this - and you can > accomplish such a thing in about half a dozen ways - illustrates the power > of MooTools Core. If this function is really useful to you, you can add it. > > > > On a personal level, my current project (Cloudera's Hue) is one of the most > JavaScript heavy things I've ever worked on - there's more JS in it than > MooTools Core and More combined and doubled - I use bindWithEvent once > (we're still on 1.2). > > > > That said, several people here have expressed some reservations about its > removal and we are discussing it in the dev channel. We listen to you guys. > It's not impossible that we may one day add it back (I'm not on the Core > team, so it's not up to me), but I doubt it. Again, this doesn't affect you; > you can use it all day long whether we put it in Core or not. > > > > Aaron > > > > On Tue, Feb 8, 2011 at 8:34 PM, Steve Onnis <[email protected]> > wrote: > > I really have to disagree with this statement Aaron. > > If you are going to remove functionality then that functionality > should be either absorbed by other functionality or replaced by > something that can acheive the same result. > > This is a prime example. You have bind() and bindWithEvent(). They > both do the same thing except one passed in an event, so if you get > rid of bindWithEvent() then the bind() method should be able to take > an event argument so it can handle the binding of the event also. > > Why couldnt it be something like bind(bindThing, [args], > withEvent[true/false) and just default the withEvent to be false. At > lease that way you cover both with one function and you dont remove > functionality that people are obviously using, especially when it come > to events. I would have thought that if you are dealing with an event > and you are binding something to it that you most definatly need a way > to deal with the event itself, so not being able to pass it back into > the handler is definatly an oversight. > > Steve > > > > > On Jan 5, 4:11 am, Aaron Newton <[email protected]> wrote: > > > It's not really less than optimal. That's the power of MooTools. If you > need > > something, you can have it. The object of MooTools Core is not to have > > everything that everyone wants, but to be the tools that allow everyone > to > > have what they want. It's perfection is not found by how much we can add, > > but rather how much we can take away. > > > > > > > > > On Tue, Jan 4, 2011 at 5:37 AM, Roman Land <[email protected]> wrote: > > > Thanks Aaron, > > > > > Would love to know why.. > > > > > I will probably add this to my code but this is less then optimal.... > > > > > Cheers > > > Roman > > > > > > On Tue, Jan 4, 2011 at 12:02 AM, Aaron Newton <[email protected]> > wrote: > > > > >> I'll let someone else answer the "why" for you, but you can always > just > > >> add it back to your own environment: > > > > >> Function.implement({ > > >> bindWithEvent: function(bind, args){ > > >> var self = this; > > >> if (args != null) args = Array.from(args); > > >> return function(event){ > > >> return self.apply(bind, (args == null) ? arguments : > > >> [event].concat(args)); > > >> }; > > >> } > > >> }); > > > > > >> On Mon, Jan 3, 2011 at 1:45 PM, Roman Land <[email protected]> > wrote: > > > > >>> Hi, > > > > >>> Wondering here why exactly BindWithEvent was deprecated? > > > > >>> Its a very useful func, it now requires me to write more code instead > of > > >>> using that simple func to pass an extra parameter into an event > callback.. > > >>> So why was it deprecated please tell me?? > > > > >>> Anyway, > > >>> Nice day! > > > > >>> -- > > >>> --- > > >>> "Make everything as simple as possible, but not simpler." > > > > >>> - Albert Einstein > > > > > -- > > > --- > > > "Make everything as simple as possible, but not simpler." > > > > > > - Albert Einstein- Hide quoted text - > > > > - Show quoted text - > > > > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 7.0.0.21, Virus/Spyware Database: 6.16860) > http://www.pctools.com<http://www.pctools.com/?cclick=EmailFooterClean_51> > ======= > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 7.0.0.21, Virus/Spyware Database: 6.16860) > http://www.pctools.com<http://www.pctools.com/?cclick=EmailFooterClean_51> > ======= > -- --- "Make everything as simple as possible, but not simpler." - Albert Einstein
