Why can we express in a property descriptor the notion of writable, configurable or enumerable but not private?
Also, could be off topic, but the fact that for a getter/setter foo property, you have to implement yourself a non-enumerable _foo property to actually have some storage, is not particularly convenient. A solution to that would be welcome! If a local variable following the name of the property was added to the scope of the getter/setter while it's called on an object could be one way, it would certainly encourage following encapsulation rather than accessing a private property directly, which would still be possible. My .02 Thanks, Benoit On Jan 21, 2013, at 12:39, Kevin Smith <[email protected]> wrote: > == Duck, or Rabbit? == > > The debate on whether to express encapsulated state using WeakMaps or private > symbols reminds me of this famous image: > > http://upload.wikimedia.org/wikipedia/commons/4/45/Duck-Rabbit_illusion.jpg > > Is private state a duck (WeakMap) or is it a rabbit (private symbol keyed > object property)? Well, both and neither. > > A private symbol is a relationship which conceptualizes the private data > "inside" the object, and which favors time over space. After all, we can > leak garbage by simply dropping private symbol variables. > > A WeakMap is a relationship which conceptualizes the private data "outside" > of the object, and which favors space over time. If the WeakMap is > unreachable, then we can collect the private data. > > In either case, we are dealing with two separate, orthogonal issues: > > 1) Do we conceptualize the private state "inside" of an object or "outside"? > 2) Do we favor time or do we favor space? > > These questioned should be resolved independently. Doing so will allow us to > avoid the duck vs. rabbit dilemma. > > == Where Does the Data Live? == > > In ES5, there is no distinction between "public" and "private" data within an > object. If you want to create private data, you must do so using a closure. > All private data is therefore "external" to the object in question. The data > does not "follow" the object around. This is a simple model. It is easy to > reason about. It's not clear that this model is insufficient for our needs. > > Introducing an additional abstraction which places private data *inside* of > the object represents a fundamental change in the ES conceptual model. We > should strive to avoid such additions to object semantics, if other means are > possible. > > == Time or Space? == > > The decision of whether to implement private data relationships inside of an > ES engine as links from one object to another, or as an entry in a > supplemental data structure, is a question of *optimization, not > conceptualization*. A user (or the engine itself) should be able to decide > on the characteristics of this optimization without affecting the > conceptualization of the relationship. > > == Conclusion == > > Private data should be represented as "outside" of the object in question. > Syntax can be added in future versions of the language to make the expression > of such private relationships more concise. If engines are not capable of > optimizing the relationship appropriately for time or space, there should be > a way for the user to select the optimization preference, either through a > WeakMap option or through a separate class with an identical API. > > { Kevin } > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
