Ok, that makes sense. I had a feeling it had to do with readability,
but I wasn't sure. Thanks for the clarification.
On Sep 17, 3:53 pm, nutron <[EMAIL PROTECTED]> wrote:
> First, $$().<anymethod> iterates over the collection anyway, so using .each
> (or some other iterator) isn't going to slow anything down.
>
> Secondly, the "this" keyword can get very confusing in code, and I try to
> make my code easy (for myself and others) to read. If I have a reference to
> something already (your $$(someClass) collects DOM elements) I'm more
> inclined to reuse that reference if I can. Avoiding the need to make a
> reference to *this* to keep it straight is something that feels, to me, a
> little hacky. Not a lot hacky, but a little hacky.
>
> The way I expressed the example above is how I would write it. I only use
> the $$().<somemethod> shortcut when I have very concise things to express.
> So, for example, I'll do:
>
> $$('div.foo').hide(); //hide is a shortcut I define in the Clientside libs
>
> but I'm a little less likely to do something that's more complex than that.
> Frankly, I don't use that shortcut method ($$().foo...) often because it's a
> little to easy to accidentally come back and chain something else to it:
>
> $$('div.foo').hide().addClass('bar'); //this iterates twice
>
> So as I said before, the way you were solving the problem is not a bad way
> to do it, but it's not how I would. Whenever binding is needed, I try and be
> as clear as I can what *this* is. Especially when I'm writing a class.
> Whenever possible, *this* in my classes is always the instance of that
> class.
>
>
>
> VirtuosiMedia wrote:
>
> > Thanks for the quick reply. Just for clarification, if you have a
> > moment, could you perhaps explain why you would choose to iterate over
> > the elements rather than use a proxy variable? In my example, I'm
> > assuming that the iteration is implied, so it essentially does the
> > same thing as what you wrote, but it seems like it saves a line of
> > code. If the event were 'mouseover' rather than 'click' and you need
> > to have something similar for 'mouseout', you could save two lines. Do
> > you feel like it's more readable to explicitly iterate? I'm not too
> > familiar on conventions, etc, so I'm genuinely curious. Thanks again.
>
> > On Sep 17, 3:16 pm, nutron <[EMAIL PROTECTED]> wrote:
> >> In this particular instance, I'd iterate over the elements instead:
>
> >> $$(someClass).each(function(el) {
> >> el.addEvent('click', function(){
> >> el.addClass('someOtherClass');
> >> this.someFunction();
> >> }.bind(this));
>
> >> }, this);
>
> >> It's not bad form to make a reference to this into another variable name
> >> (as
> >> you have in your example) but I find it's rarely needed. In all the code
> >> I've written for the Clientside libraries, I can't think of an instance
> >> where I've had to do it. If so, it's only once or twice.
>
> >> VirtuosiMedia wrote:
>
> >> > Is there a better way to do have multiple 'this' references inside an
> >> > addEvent function? Right now I'm using a variable called thisProxy to
> >> > refer the global this and the this inside the function will refer to
> >> > that instance. I don't want to use bind because I need them both. Is
> >> > there a more elegant method?
>
> >> > Here's an example:
>
> >> > var thisProxy = this;
>
> >> > $$(someClass).addEvent('click', function(){
> >> > this.addClass('someOtherClass');
> >> > thisProxy.someFunction();
> >> > });
>
> >> -----
> >> The MooTools Tutorial: http://www.mootorial.comwww.mootorial.com
> >> CNET Clientside: http://clientside.cnet.comclientside.cnet.com
> >> --
> >> View this message in
> >> context:http://n2.nabble.com/Multiple-this-references-inside-the-addEvent-fun...
> >> Sent from the MooTools Users mailing list archive at Nabble.com.
>
> -----
> The MooTools Tutorial: http://www.mootorial.comwww.mootorial.com
> CNET Clientside: http://clientside.cnet.comclientside.cnet.com
> --
> View this message in
> context:http://n2.nabble.com/Multiple-this-references-inside-the-addEvent-fun...
> Sent from the MooTools Users mailing list archive at Nabble.com.
