Brendan Eich (2013-07-25T21:17:15.000Z)
domenic at domenicdenicola.com (2013-08-02T19:56:21.452Z)
Axel Rauschmayer wrote: > More of an aside: I think it would help if we had a list of what > people actually want from privacy. > > I want: > > 1) Avoiding name clashes > > 2) Indicate that a property is not part of the public API of an object > (along with support from an IDE and a reflective API) > > Other people seem to want: > > 3) Completely protecting data from external access. 3's "external access" must include reflection (proxies). You left out 4) Convenient syntax, e.g. `obj@priv` from relationships, and not `obj[privSymValue]`. > Currently, symbols take care of #1. They don’t really take care of #2, > because we probably want some symbols to be part of the public API of > an object. We definitely do: @@iterator in the ES6 draft, for example. > Another possibility to support #2 (but not #1): a naming convention > for properties. We aren't doing more dunder names. > \#3 seems to be well covered by either closures or weak maps. No, see 4 and also consider that we must not require a weak map, since per relationships those are mutable so side channels, and for optimization purposes we don't even want to create a weak map even if one could suffice, where the private fields are class-affine and live longer than all instances. Symbols (unique names that can't be forged and which do not leak via reflection) under the hood work much better there. Arv's proposal is about symbol though, not private state in classes. Note all its class examples use symbols that are unique and quite public. The idea is to clear the decks for private state as a separate proposal (see again http://wiki.ecmascript.org/doku.php?id=strawman:relationships) from symbols, and do away with private vs. unique symbols.