Private Slots

Claus Reinke claus.reinke at
Tue Jan 15 02:02:05 PST 2013

> It's really none of your business when you try to freeze my object 
> whether any of
> (a) pre-existing private-symbol-named properties remain writable;
> (b) weakmap-encoded private state remains writable;
> (c) objects-as-closures environment variables remain writable.
> Really. Not. Your (user). Business!

But it is Your (author) business, and turning everything into
a proxy to get control over how the authored objects behave
seems a little excessive. And the same thing applies to clone/

It has been pointed out that the issue is one of implicitly called
iterators: standard methods for freezing or cloning call iterators 
that only handle public API.

I have suggested before that it would be good to put control
over object iteration into the hands of the object authors, by
enabling them to override the slot iteration method. 

One would need to find a way of doing so without exposing 
private names, but it should allow object authors to handle 
your a-c, as well as define what cloning/mixing should do in
the presence of private state (however encoded, although
private slots might make this easier/more explicit).


More information about the es-discuss mailing list