I usually prefer $this. I find it the most descriptive, plus, many editors (such as vim) highlight it as well.
On Mon, May 2, 2011 at 8:33 AM, Sean McArthur <[email protected]>wrote: > Its not because you can't access the original "self", but that if you > forget to declare the variable, you'll possibly have no errors thrown as you > use the wrong object. > On May 1, 2011 8:22 PM, "Ryan Florence" <[email protected]> wrote: > > https://developer.mozilla.org/en/DOM/window.self > > > > Not part of the spec, and `window.self` is still around wI usually > prefehenever 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 > >> > > > -- Arieh Glazer אריה גלזר 052-5348-561 http://www.arieh.co.il http://www.link-wd.co.il
