> 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:
this.foo = function (...} {...};
to
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.
[1] http://www.python.org/dev/peps/pep-0318/
>> 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
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
