Re: whether [Callback=FunctionOnly] should be the default

On Wed, Jun 29, 2011 at 12:01 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 28 Jun 2011, Boris Zbarsky wrote:
> >
> > This pattern doesn't work well if what you want is to encapsulate state
> > including a given prototype chain and the like.  Sure, you can hack it
> > all with a closure because you can just close over everything you care
> > about and delegate things, but in some cases having an actual object
> > which ends up as the this of the callback and has a useful prototype
> > chain and whatnot is just much clearer.
>
> This is probably just a personal preference thing. Personally I've never
> really found the prototype mechanism in JS to be especially intuitive and
> so the idea of using it in this way frightens me. :-)
>

Why?


> One big advantage of FunctionOnly is that the code that uses the API
> cannot do complicated things such as what you describe, thus making code
> that uses the API simpler to understand, IMHO.
>

My sense here is that this is a JS language problem: the inability to bind
your calling context is the real bugbear. ES recently added
Function.prototype.bind which allows methods to be hitched like:

   n.addEventListener(object.method.bind(object), ...);

But the syntax (or lack thereof) sucks and digging the triggering object
back out of the Event object is something of a pain. Better would be a
de-reference syntax for functions-used-as-methods that gives you a soft
binding to some context:

  n.addEventListener(object->method, ...);

Regards


> But that's rather subjective, I'll be the first to admit.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>