Scoped binding of a method to an object

Andreas Rossberg rossberg at
Mon Oct 14 02:13:27 PDT 2013

On 13 October 2013 19:49, Brendan Eich <brendan at> wrote:
>> Erik Arvidsson <mailto:erik.arvidsson at>
>> October 13, 2013 10:32 AM
>> We did proposes this back in 2011
>> I wasn't at this actual F2F meeting so I don't know many details.
>> Brendan might remember what the blocking issue was?
> I wrote why in my reply, cited below:
>> Your subject recalls a defunct proposal to add lexically-scoped but
>> heap-based -- therefore object property-lookup performance hindering --
>> extension properties. This proposal died precise because of the performance
>> problem.
> Every property access sprouts a third parameter beyond object and property
> name, namely a lexical scope token of some kind. All property maps in
> objects shared in the heap also sprout such a scope token along with
> property name.
> (This is quite reminiscent of ES4 namespaces, which we agreed to reject from
> any future ECMA-262 in order to forge Harmony in 2008. See
> Implementors objected, including V8 folks (if I recall correctly, Andreas
> Rossberg). This was at the May 2011 TC39 meeting hosted at the University of
> California at Santa Cruz.

I wasn't at that meeting, but yes, the V8 team strongly objected to
this. A scope-dependent, 2-dimensional lookup matrix (even
3-dimensional for variables inside 'with') would be an utter nightmare
in terms of complexity and optimisation (even by JS VM standards).
Also, the concrete proposal had questionable semantics. Fixing them
properly would indeed have brought us back full circle to ES4-style
namespaces, as Waldemar argued convincingly at some point.

My take-away was that scoped extension methods are only bearable in a
language with a static, nominal class system (like C#), where the
additional lookup dimension can be resolved at compile time.


More information about the es-discuss mailing list