Private Slots

Brendan Eich 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/
> 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


More information about the es-discuss mailing list