Ducks, Rabbits, and Privacy

Benoit Marchant marchant at mac.com
Mon Jan 21 22:31:28 PST 2013


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 <khs4473 at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130121/2ef93c3b/attachment.html>


More information about the es-discuss mailing list