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