claus.reinke at talk21.com
Thu Jan 17 12:53:36 PST 2013
>>> 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
> 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?
More information about the es-discuss