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.

I was assuming that proxies would be able to intercept freeze
and implement matching behavior for private slots.

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 freeze 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.

True, private symbols as first-class objects can hide anywhere.

I was thinking in terms of private slots as limited to the instance
(hoping to translate existing private symbol property names to fresh private symbols, thereby supporting mixins without exposing the existing private symbols), but even if that was the case, one would quickly end up with the complexity of a deep-cloning operation, which could only be provided as a primitive/built-in.

For the special case of freeze, perhaps a 'freezable' attribute is all
that is needed to include private slots in the freeze iteration, without
exposing them.

Your -- as in You the abstraction implementor -- may indeed make such state observable.

But if I do not have a way to hook into freeze, etc, how do I make
my objects with hidden state behave like objects with exposed state?

Claus

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to