David Bruant wrote:
Le 20/01/2013 18:59, Brendan Eich a écrit :
David Bruant wrote:
I disagree with Brendan when he says "to use weakmaps for class
private instance methods/variables"... well... it depends on what
"use" means:
The spec is allowed to /use/ anything it needs to make the class
private syntax work. If the spec says that private properties are
like properties but aren't enumerated in Object.gOPN calls, fine. If
the spec says that private properties require a lookup to some
object -> value map, fine (but misleading, I agree).
I don't think we disagree.
If there were no observable differences at all between weak maps and
private symbols, we would have only one. Since there are, and since
you propose to map private-in-class syntax onto weak maps in part on
account of these differences (viz, proxying and whitelist population
without privacy-leaks), here we are.
I don't understand, this paragraph went too quickly.
I understand that you're saying that the proposal I defend (which
includes getting rid of private symbols) relies on the differences
between private symbols and weakmaps and hence both are necessary?
Am I fully misunderstanding?
I think you are misreading, and we're going off track. You did not agree
with my use of "use". I'm not sure why, but my second reply about
wanting to minimize kernel semantics in the spec, and thereby support
desugaring/trans-compilation, may shed light on the deeper issue (if
there is one).
In none of this did I try to make a case for private symbols and weak
maps. That case has been made but I'm not going to rehash it, and your
argument predicated on private-in-class for weak maps is a fine argument
to make (assuming the predicate condition, which is not true for ES6 --
no private syntax in class syntax yet!).
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
