Kevin Smith wrote:
It's really none of your business when you try to freeze my object
whether any of
(a) pre-existing private-symbol-named properties remain writable;
(b) weakmap-encoded private state remains writable;
(c) objects-as-closures environment variables remain writable.
Really. Not. Your. Business!
But that's a change from the current object model
(b) is a change from ES5 but you don't object to weak maps -- why not?
(c) is not a change from JS's object model!
and by (a) you're assuming the conclusion.
No, I'm saying the horse already left the barn.
ES has a really simple object model, as explained in the first part
of the ES5 specification. That simplicity is an advantage. If you're
going add complexity, then it should be justified with
application-focused use cases. That request does not seem like a
stretch to me.
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.
Finally, efficiency does matter. The GC cost of weak maps is just one
cost I mentioned. The property access cost is another, which you did not
address.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
