Kevin Smith wrote:
(b) is a change from ES5 but you don't object to weak maps -- why not?
WeakMaps provide a new feature without extending the object model.
They are "external" to objects, if you like.
They are a kind of object, on the contrary.
(c) is not a change from JS's object model!
Sure - but I'm not objecting to closed-over state (in any form). That
would be ludicrous. : )
But that's part of the object model, no? If so, the CoffeeScript
summary-manqué is not worth much, and your argument from it, even less
so :-|.
and by (a) you're assuming the conclusion.
No, I'm saying the horse already left the barn.
Again, not objecting to private state. But just because we allow
private state, it does not necessarily follow that we should mess with
the object model to accomodate it.
I think you've chosen a cartoon-short version of "the object model" to
argue selectively against other things.
Maybe it's worth it, I don't know. That's the whole point: I don't
know. And when in doubt...
Hold that thought.
Of course, we justified weak maps with specific use-cases. Those
do not cover private symbols, because private symbols are really
"in" the object, they do not identify storage in a side table.
This matters when abstracting over strings or symbol (private or
unique) property names, as I showed. It matters when using the
bracketing operator (a weak map would have to be exposed and its
use transposes operands of []). It matters for any future private
syntax.
But is this not premature optimization? How do I know that WeakMaps
and Proxies are insufficient?
Realistically, O-O commonplaces such as private fields and methods
should not require a proxy or a weakmap, or they won't see much use.
It may be that high-integrity privacy won't see much use anyway (your
point?). But it has its uses (SES is being used on the web now, details
coming).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
