brendan at mozilla.com
Tue Jan 15 10:28:22 PST 2013
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/
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
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++.
More information about the es-discuss