Axel Rauschmayer wrote:
JS is functional first, not OOP first. APIs that want methods to be
extractable as bound to the object from which they were extracted
must do extra work, which can be self-hosted via getters for specific
methods, or a general proxy.
Again, not sure if that’s feasible, but it would help if one could
make the distinction between a property being read (“get”) and a
method being invoked (“call”).
{
function extractableMethod(...) { ... }
Object.defineProperty(Foo.prototype, 'extractableMethod', {
get() {
return extractableMethod.bind(Foo.prototype);
},
call(...args) {
return extractableMethod.call(Foo.prototype, ...args);
}
});
}
Good point, the getter would bind even for calls that don't need it.
Proxies don't help because their design eschewed an 'invoke' trap in
favor of minimalism and JS high-fidelity.
So I'm wrong, and this does up the ante for a built-in solution, the
bind operator.
Still messy and probably not backwards compatible, so a bind operator
might be a better idea, after all:
elem.onclick = obj::foo; // or the proposed ::obj.foo
instead of
elem.onclick = obj.foo.bind(obj);
Yes, this is Dave's proposal (the ::obj.foo syntax is better in my view
and it's there, just not in the grammar sketch):
http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
