Scoped binding of a method to an object

Brendan Eich brendan at
Mon Oct 14 11:30:07 PDT 2013

> John Lenz <mailto:concavelenz at>
> October 14, 2013 9:59 AM
> Does this performance hit still exist in light of Symbol?

Yes. Symbol is just an alternative property name type. Think of it in 

   type PropertyName = String | Symbol

where of course practical engines optimize further by recognizing index 
names (strings that contain integers within certain bounds) and 
representing them as boxed or tagged machine integers.

Symbols do not add a third parameter (scope token, namespace qualifier, 
Common Lisp symbol package).

> It seems you could build  lexical extensions on top of it without 
> introducing a performance penalty.

Something like this was proposed in the early days of symbols, then 
called names (also "private names"):

People objected (Andrew Dupont started the ball rolling, see and 
read the whole thread) to adding a static (compile-time-only) 
after-dot-in-property-expression/after-colon-in-object-literal name 
lookup chain.

The objection has a specific and a general aspect:

Specific: once a private foo; declaration is in scope, especially for a 
large scope, it is hard to avoid errors reusing the name (or using it on 
unrelated objects) without the private binding tainting all 
after-dot/colon uses.

General: JS users are not used to thinking about the name after the dot 
as being looked up in any chain other than the prototype chain. Adding a 
lookup chain, even if only compile-time, will break users' brains enough 
to add significant bug habitat.

I'm not sure how to overcome these, but I bet that if there's a way, 
then classes play a part. Within the scope of a class body one is most 
likely to want something like private names in scope. Indeed Oliver Hunt 
and others have wished for this, but it does not work for class-private 
instance variables in dynamically typed JS:

   class Point {
     private x, y; // made-up syntax, not the point so carry on...
     add(other) { return Point(this.x + other.x, this.y + other.y); }

We require this.x, not just x, for the instance variable, because we 
must be able to express other.x as well.

The alternative more recently discussed for relationships would use @ 
not dot as the connective when denoting private members. That avoids the 
issue for private name uses alongside public 'x' and 'y', but does not 
relieve us from requiring private declarations of some kind. And @ does 
not help with classboxes or scoped object extensions.

So let's set aside @ for the moment. As shown above, if we had something 
like private name binding declarations, then the use of 'x' or 'y' 
inside the body after dot-in-property-expression or 
colon-in-object-literal would always denote the private names, not the 
string-equated namest.

If this is tolerable (modulo how the design issues around declaring 
private x and y), then perhaps classboxes in JS can be built similarly.

Lot of "ifs" here.


More information about the es-discuss mailing list