10 biggest JS pitfalls

Brendan Eich brendan at mozilla.com
Sun Dec 30 15:44:13 PST 2012


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


More information about the es-discuss mailing list