Some questions about Private Name Objects

Claus Reinke claus.reinke at
Tue Aug 28 13:11:41 PDT 2012

> Unique (non-private) names offer mixins without collisions.  But any
> general mixin utility will fail if the source  object relies on privately
> named methods for its functionality:
>  ...
> Neither the destination object nor the library function "mixin" has access
> to the private name, and therefore the privately named method will not get
> copied to the destination object, and the mixin will fail.
> Clearly the solution above would be to use a unique name, instead of a
> private name.  

Alternatively, and this has a more OOP feeling to it, one could
put the objects in control of iterations, with separate, overridable
iterators for separate purposes. One such purpose would be an
iterator to be used for an object clone/extend operator. The default
clone iterator would skip private properties, but those could be
added by overriding.

Such a clone operator would itself need to be private, only
callable for property copying (eg, with a built-in extend), but
with this caveat, it should be possible to copy private properties
without exposing their keys, and with the source object in full
control of whether or not private properties may be copied.

Is this line of reasoning too far off, or has it been considered
to add such extend/clone iterators?


More information about the es-discuss mailing list