Allen Wirfs-Brock wrote:
On Jan 19, 2013, at 6:02 PM, Brendan Eich wrote:
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.
No, I'm talking about plain old Object instances that are frozen and
live long enough.
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.
Quite agree.
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.
That seems to be agreed upon by everyone (anyone dissent?).
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.
Agreed, but the live proposal here is to use weakmaps for class private
instance methods/variables, and not have private symbols.
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);
}
}
Right, but could you have "classes as sugar" including private syntax as
David proposed (based on weak maps) that can access prototype-delegated
properties? (I guess they would be 'protected' in that case.)
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
