On Jan 19, 2013, at 6:02 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> Who's to say that a symbol keyed object
>
> You must mean "property" not "object".
of couse
>
>> can't be added to an object after Object.freeze has been applied to it.
>> Before we can say that we have to define the semantics of symbol keyed
>> objects and possibly extend Object.freeze/isFrozen to accommodate those new
>> semantics. What's the guidance for doing so? What abstract concept of
>> "frozen" do we to apply to the semantics of new language features?
>
> This is not an abstract question. Implementors may want
> Object.preventExtensions to put an object in a state such that optimizations
> can rely on it never growing new properties.
Then are we talking about what I would probably call non-extensible objects.
You are saying you want the "shape" of the object to be fixed.
> Frozen objects could even be promoted by a copying GC into read-only memory,
> with the OS virtualized hardware MMU providing greater integrity.
But here you are talking about some broader from of immutability that
presumably includes non-property per instance state (eg, "internal data
properties") and any sort of "private" per instance state that the language
provides. Either of those go beyond what ES5 Object.preventExtensions or even
Object.freeze provides.
>
> More to the point, programmers may wish a frozen object o having properties p
> and q, and null or frozen prototype chain of known properties, never to grow
> property r. Whereas using weakmaps explicitly, of course one can call
> r.set(o, v) to set r's value to v.
Right, they may. My point we is that we have to decide on all the
characteristics of a "frozen" object before we can answer all of these
questions.
I like the fact that you used "r" as a name above because certainly a WeakMap
can be used to define a relationship involving an immutable object o. But we
shouldn't be creating confusion by pretending that those relationships are the
samething as a property of o or anyway part of o. Such a relationship is an
independent entity that exists separately from o and can be defined
independently of o.
>
> If we are talking about private syntax only in classes, this may not matter.
> Either private symbols or weak maps suffice.
I think a very important characteristic of classes is that they really are just
sugar and don't have any special magic. We should try to maintain that
characteristic.
> But proxies can tell, and prototype-based inheritance works for private
> symbols but not weak maps.
>
> So even if we allow a frozen object to grow new private-symbol-keyed
> properties not in that object at the time it was frozen (or let's say the
> time Object.preventExtensions or its internal form was invoked), private
> symbols and weak maps are distinguishable. If they weren't, we surely would
> have no need for one or the other.
Well, then we are probably debating about how much we agree with each other.
Weakmaps and private Symbols are totally different things. Just because some
problems can be solved with either one doesn't make them equivalent.
But, that said, you certainly could use Weakmaps to define a style of
relationship that supports inheritance like mention above. Just create a
subclass of Weakmap like:
class WeakMapWithKeyInheritance extends Weakmap {
has(key) {
if (super.has(key)) return true;
let proto = Object.getPrototypeOf(key);
If (proto === null) return false;
return this.has(proto);
}
get(key) {
if (super.has(key)) return super.get(key);
let proto = Object.getPrototypeOf(key);
If (proto === null) return false;
return this.get(proto);
}
}
Allen
>
> /be
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
