brendan at mozilla.com
Tue Jan 15 11:21:12 PST 2013
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
> 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
> 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
More information about the es-discuss