Bound instance-function vending (was RE: Arrow binding)

Axel Rauschmayer axel at
Sun Apr 29 10:10:41 PDT 2012

> If I understand correctly, this approach negates the need for a mixin function entirely - localStorage could just be an old style mixin hash. 
> But either way this tosses out the benefits I get from functional mixins. By invoking the mixin instead of copying it I can a) customize it's behavior by passing it arguments b) have the mixin add "advice" (before, after, around) to functions of the target object.

For me, conceptually, localStorage() is a non-method function that has a single parameter. I don’t think the capabilities are impaired if you change each occurrence of: = function (...} {...};
    Object.extend(obj, {
        foo(...) { ... },

Object.extend would automatically invoke Object.defineMethod() (or similar) for you, to enable super-references (but I doubt there is much use for them in mixins).

Admittedly, if there is only a single method then there is a lot of unnecessary syntactic noise. However, methods tend to appear in groups (implementing protocols). Putting such groups in object literals makes much sense.

As an aside: If you want to annotate methods then function expressions are indeed a plus, because they can be immediately invoked. Python has method decorators for this [1].

myExtend(obj, { someMethod: function (inner, arg) { doSomething(); var result = inner(arg); result++; return result }.around() });

A bit hacky, but nicely declarative. Function.prototype.around() would tag the method, later post-processing would perform the transformation.


>> It would be my hope that we can replace all previous rules with the two rules above. `apply` will mostly be replaced by the spread operator, `call` will mostly be replaced by calling a value. Some code such as `forEach` implementations that previously needed to use `call` to simulate lexical scoping don’t need a `thisValue` parameter for array functions.
> I admire the vision but in reality the boundary between ES5 and ES6 will be messy and drawn out - there will be no clear cut switching point. Legacy code must live alongside the new vision. Without a new strict mode which banishes much of the old spec (and kills my functional mixins) I'm finding it hard not to picture chaos. (and how do you shim => anyway?)

Right. I think you can still tell a simple story to beginners while supporting thin arrow or (this, ...) => {} for legacy software.

But I’d hope that the old code can be cleanly separated and that a new coding style will be supported by static checking tools such as JSLint.

Dr. Axel Rauschmayer
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list