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