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 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
>>
>
