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
> <http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields> 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
> <http://wiki.ecmascript.org/doku.php?id=strawman:private_names#conflict-free_object_extension_using_private_names>
> 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.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
