Scoped binding of a method to an object

Brendan Eich brendan at mozilla.com
Sun Oct 13 11:37:02 PDT 2013


> Benjamin (Inglor) Gruenbaum <mailto:inglor at gmail.com>
> October 13, 2013 11:00 AM
> Brendan Eich<brendan at mozilla.com <mailto:brendan at mozilla.com>> wrote:
> > No, object detection, polyfilling, and even "prollyfilling" are 
> common and successful adaptationsp on the Web.
>
> Polyfilling is great _after_ the method has already been added to the 
> spec.

Prollyfilling is great too (perhaps you disagree?), and as its name 
suggests it happens *before* the method is added to the spec.

> I'm completely fine with adding an Array.prototype.map shim to IE8, 
> the problem with adding a method that's not on the prototype yet is 
> that it'll fail in case the spec is different from the implementation 
> I chose. If you mentioned PrototypeJS, its `.bind` method is one such 
> example.

How exactly did that example "fail"? The differences in detail hardly 
matter; PrototypeJS trod a cow-path that ES5 paved. Most users don't 
worry about the edge case differences.

> > Your subject recalls a defunct proposal to add lexically-scoped but 
> heap-based -- therefore object property-lookup performance hindering 
> -- extension properties.
>
> I have to say this surprises me, a performance issue is the last thing 
> I expected. What about attaching a prototype as a closure variable, 
> something (and this is a syntax I __don't__ like) like:
> ```
> (function(use Array){
>     Array.prototype.contains = function() { ...
>     ...
>     // any code here has access to .contains, code that did not 
> originate here does not have such access, much like a closure.
>     // other code is free to use Array without any collisions.
> })()
> ```
> Again, I __don't__ like this sort of syntax and I'm __not__ sure about 
> the semantics here, I just noticed I have this problem - I'm probably 
> not the most qualified for coming up with the solution out of the 
> amazing minds right here.
>
Don't worry about syntax yet. The issue in any such semantic extension 
is the required extra lookup parameter: not just contains on the right 
of dot, but the enclosing closure scope.

Unqualified identifiers (ones not used after dot) indeed require lookup 
via closure environments, to the global (let's ignore 'with' and DOM 
inline event handlers).

Dot-qualified identifiers and equivalent bracketed computed property 
name accesses require prototype chain lookup.

No matter the syntax, and independent of details of how one specs it, 
you're proposing a hybrid of the two schemes. This must cost, and it 
does cost.

/be


More information about the es-discuss mailing list