Ducks, Rabbits, and Privacy

Kevin Smith khs4473 at gmail.com
Mon Jan 21 12:39:08 PST 2013


== 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 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130121/b52d9b42/attachment-0001.html>


More information about the es-discuss mailing list