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
needed.
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.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
