strawman for the := operator
claus.reinke at talk21.com
Wed Aug 8 13:43:43 PDT 2012
> Finally, I do have a way that we could put the cloning of private
> named properties by := under programmer control.
Giving objects control over how they appear to := and other
Object.extend variants sounds like a good idea.
> Note that private named properties are never enumerated or
> exposed via reflection. Hence, the [[Enumerable]] attribute really
> doesn't mean anything for such properties. We could enhance
> the semantics of := so that used the value of the [[Enumerable]]
> attribute to control the whether or not private named (and only
> private named) properties are cloned. I'm not thrilled with
> this idea, but it probably could work.
This seems to abuse a single property to control two different
internal iterators: for-in and :=. It is in the nature of for-in that it
exposes the enumerated properties, while := just copies them
over (if you don't have the internal private names, you still
cannot use the private properties directly).
Perhaps this situation calls for a separate iterator, now that
iterators can be defined in ES? A cloning iterator, inherited
from Object.prototype (for convenience), overridable as
If private properties can be cloned, cloning an object with
private properties would differ from cloning an object with
variables in its closure. Not being able to break sharing of
closed-over variables (emulated private state) has been an
issue for user-defined clone operations.
> If := does not replicate the private named properties that the
> public properties are dependent upon then the mixin won't
> work. Essentially, the public and private named properties
> form a cohesive unit that needs to be replicated as a unit.
That calls for a way to abort (or rather, not implement) the
:= iterator, for objects whose properties cannot be sensibly
be copied this way.
More information about the es-discuss