https://developer.mozilla.org/en/DOM/window.self
Not part of the spec, and `window.self` is still around whenever you need it. I'm still unconvinced to avoid it. Funny to be afraid assigning `self` when using a framework that mutates host objects... However, I often use something descriptive like `var element = this` or `var instance = this`. On May 1, 2011, at 8:11 AM, Stewart Mckinney wrote: > 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 >
