Claus Reinke wrote:
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.
What have proxies to do with any of a-c? I don't follow.
And the same thing applies to clone/
mixin.
Agree proxies should not be required to do standard O-O things.
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 think you're missing the point. Object.freeze deals in certain
observables. It does not free closure state, or weakmap-encoded state,
or (per the ES6 proposal) private-symbol-named property state where such
properties already exist. Those are not directly observable by the
reflection API.
Your -- as in You the abstraction implementor -- may indeed make such
state observable. That's a feature. Think of const methods with mutable
this members in C++.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
