I'm going to back up Sean; the only thing I have against 'self' is that it's also a property of the global window object that points to that object; 'that' isn't. I've seen a few instances in collegue's code where they were going bonkers trying to find why .foo() wasn't defined on their object instance, only to discover that their 'var self =' declaration was out of scope.
IMHO, "self" is becoming more and more popular primarily because of the Node.js community. It's the hot forum in which lot of technologists are voicing opinions on "new patterns for a new movement in a new age". Some of it's good, some of it's just... new. Nearly all of it is still opinion. But the reason why 'self' shines there is that, unlike a browser environment where the global object is 'window', its not a property of the global object in the headless environment. That said (get it),. you can generally avoid using that pattern 99% of the time using .bind() or the Class.Binds mutator in More. (if you are using 1.2.x +) Additionally, there's nothing wrong with using a name that describes the class you are binding to the function's closure scope, too; like "myDog" or "dog" or "tooltip" or "widget". It's really no different than naming an instance variable in imperative programming languages, at least in terms of finding voicing semantics. That can help with debugging, especially in really intense sessions where you have sooo many breakpoints and 'this' and 'that' become a little too miscible. On Sun, May 1, 2011 at 12:44 AM, Tim Wienk <[email protected]> wrote: > On Sun, May 1, 2011 at 05:11, hairbo <[email protected]> wrote: > > > > Thanks to all for the advice. I'm glad I wasn't completely 100% > > bonkers wrong on this. Maybe 30% or so, but I'll take it. > > I mentioned it in the other thread, but keeto (Mark Obcena) wrote a > really good book on javascript, and specifically how mootools uses it. > It'll teach you a lot more, and explain things more thoroughly. If you > like the 'Up the moo herd' blog posts on keetology.com, you'll like the > book as well. > > > Embarrassingly, I didn't know that I shouldn't use Event(e).stop() > > anymore (preventDefault seems the more modern way?) > > It's not the `stop` that is the problem. `stop` is a shortcut for doing > both `preventDefault` and `stopPropagation`. The thing is that since > MooTools 1.2, the event you receive as argument in the handler is > already extended. You don't have to do `new Event(e).stop()`, you could > just do `e.stop()`. > > > nor did I know I could put the "Implements" stuff into the class > > itself. > > That's a 1.2 addition as well I think, take a look at: > http://mootools.net/docs/core/Class/Class#Class:constructor > > > -- > Tim Wienk, Software Developer, MooTools Developer > E. [email protected] | W. http://tim.wienk.name >
