Hi,

>  That's true, but your example does not use .bind(), therefore I don't
> really see how it pertains to the discussion.

I was addressing your question (the one I quoted), not the bind
discussion.

> When you .bind(), you are
> passing the the function to bind, along with it's context and all that goes
> with that...

Right.  As I said, if you're doing an inline function *anyway*, it can
make sense to go direct rather than use bind -- you're already
creating the closure over the current context, why compound things
unnecessarily with bind's (admittedly slim) context?  (Go back to my
reply to your first post in this thread.)  But where you're using a
function declared *elsewhere* and your only purpose for an inline
function is setting 'this', that's where bind() makes more sense --
because you don't create a new closure over the current execution
context, which may be heavy; instead, you create a new closure over
bind()'s context, which is quite slim.

An example may help:

function outer() {
    var x, y, z;

    function nested() {
        var q, r, s;

        function moreNested() {
            var a, b, c;
            var self = this;

            new Ajax.Request(url, {
                onSuccess: function() {
                    self.handler()
                }
            }
        }
    }
}

With that structure, we're creating a closure over a deeply-nested
scope chain and preserving a, b, c, q, r, s, x, y, z, and self until
that request completes -- all just to provide handler() with its
'this' reference.

Whereas:

function outer() {
    var x, y, z;

    function nested() {
        var q, r, s;

        function moreNested() {
            var a, b, c;

            new Ajax.Request(url, {
                onSuccess: this.handler.bind(this)
            }
        }
    }
}

Here, we're *not* preserving a, b, c, q, r, s, x, y, and z, because
there's no closure.  They can be GC'd as soon as the function returns,
before the request completes.  We are (instead) preserving a fairly
slim context around bind().

Using bind with a function that's *already* inline for other reasons
is just wasteful.  But with functions defined elsewhere, it can
provide efficiency in addition to syntactic clarity.
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available

On Mar 11, 4:00 pm, Ryan Gahl <ryan.g...@gmail.com> wrote:
> > If we recast our example to use a named function for the handler:
>
> > function init() {
> >    var container;
>
> >    container = $('container');
> >    hookUpHideables(container);
> >    container.show();
>
> >    function hookUpHideables(p) {
> >        p.select('.hideable').invoke('observe', 'click', hideableClick);
> >    }
> > }
>
> > function hideableClick(evt) {
> >    this.hide();
> > }
>
> > ...no closures have outstanding references at the end of init(), and
> > the chain is eligible for GC.
>
>  That's true, but your example does not use .bind(), therefore I don't
> really see how it pertains to the discussion. When you .bind(), you are
> passing the the function to bind, along with it's context and all that goes
> with that... so I really can't see how it's any better than inlining, except
> just on a pure convenience level. Keep in mind we're talking about cases
> where you need to "correct" the scope of the bound function so that "this"
> is your class's object instance. Your example here is a completely different
> scenario where the developer doesn't care that "this" is the element itself.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to