strawman for the := operator

Claus Reinke claus.reinke at
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 mailing list