New private names proposal

Allen Wirfs-Brock allen at
Thu Dec 23 15:51:45 PST 2010

On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:

> You've said this "apples to oranges" thing many times. I just don't get it. My comparisons at <> show that these two semantics address extremely overlapping use cases. For both to be in the language, with one group (including myself) saying "use soft fields for these use cases" and another group saying the opposite, is to create conflicting conventions and the horrors of Perl's TIMTOWTDI philosophy. 
> Do you agree at least that for the use case shown by the <> clone example, we should all recommend soft fields, so that these extensions will not needlessly break when they encounter frozen prototypes?

I'll echo Brendan's and D. Herman's no.  But let me take my own crack at trying to explain what I think the difference is.

I believe that your  "camp" wants to think of soft fields, stored in a side-table, as extensions of an object.  My "camp" thinks of such side-tables as a means of recording information about an object without actually extending the object.

Object oriented programming is largely about  identifying abstractions and providing their implementations.  Each abstraction has a set of public characteristics.  The naming of an abstraction allows us to intellectually chunk a set of characteristics as a single named concept.  This makes it easier to conceptualize complex systems.  One of the possible characteristic of such abstractions is whether or not the implementation of the abstraction (the class or object, depending upon the language) may be extended or modified.  In ES5, I think of the [[Exstensible]] internal property as the mechanism for implementing this characteristic.

There are situations where it is convenient to extend an object (and hence the abstraction it implements).  There are also situations where it is necessary to record information about an object without extending the object or the abstraction.  There are also situation whether either approach might reasonably be used.

The clone example, in my proposal is explicitly addressing the case of how you might use "private names" to extend an extensible object is a way that avoids naming conflicts. It does not apply to frozen objects because such object are simply not extensible.   A similar example could be adding the "array extra" methods to Array.prototype in an ES3 implementation that also included the [[Extensible]] internal property.  As long as [[Extensible]] was true you could add those methods.  But if [[Extensible]] is false you can't do it.  It isn't simply a matter of finding a different way  to extend the Array.prototype abstraction  (perhaps adding analogous functions to the Array Constructor).  Array.prototype simply can not be extended if [[Extensible]] is false. Whatever you do you will not be extending the array abstraction.  Instead you will be creating a new parallel mechanism that operates in conjunction with the array abstraction.  Extending Array.prototype with a map functions allows you to integrate map into the array abstraction.  You don't have to think about it independently.  If Array.prototype is frozen you can't do this.  You have to think about an independent map function.

Whether or not to support an extensible abstraction is a design decision for the original creator of the abstraction.  The designer of a AST framework might  make its node abstraction extensible so that clients could directly decorate the AST.  That decision becomes part of the abstraction.  Given that decision, a client of the frame might choose to extend the node abstraction.  Or it might choose to create new abstractions (perhaps via side-tables) to record information about specific nodes.  If the framework designer choose to make the node abstraction non-extensible (for reasons of parallelism or whatever) the client has no choice in the matter.  They must accomplish their goal without extending the node abstraction.

Weak map based side tables are a great tools for associating supplemental information with an object.  But that information is not part of the abstraction represented by the mapped objects.  It is part of some new abstraction.  By treating such Weak maps as "soft fields" you seem to be trying merge the two abstraction in a manner that imposes inconsistencies.  Specifically the merged abstraction is both frozen and extensible, yet frozen is the JavaScript object level manifestation of a non-extensible abstraction.

A apologize if this explanation is still unclear.  I think we are indeed conceptualizing things quite differently which is why you see an isomorphism where I see a dichotomy.  Hopefully, we can continue to try to develop a shared understanding.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list