On Jan 20, 2013, at 3:04 AM, David Bruant wrote: > Le 20/01/2013 05:27, Allen Wirfs-Brock a écrit : >> Weakmaps and symbol keyed properties (private or not) are very different >> mechanism. They each have a variety of uses and differing implementation >> and performance characteristics. It really is a distraction to focus >> exclusively on a single use case that might be supported by two different >> mechanism and use it to argue that only one of the mechanism is needed. > What are the different uses of private symbols?
Branding is the important one. Secure private communications between "friend" objects is another possible one. > More specifically: what are the remaining explicit uses of private symbols in > a language with private syntax in classes? But we don't have such a language. There are no harmonious proposals for such a syntax. Getting classes into ES6 via the max-min class proposal was possible because we agreed not to debate that issue. We we were going to talk about adding support for addition semantics to classes we should start at the level of the object model. Not with syntax. ES6 class syntax is good because it is defined in terms of the object model and more basic operations that are defined in the language. You don't have to use class syntax to define a class equivalent. So, if we are going to introduce private object state the first step is to define how it works at the object model level. IMO and for reasons I've already presented, saying that private state is just relationships defined via WeakMaps is a non-starter. > > I think symbols were introduced given experience in ES5 and assuming being an > improvement on top of ES5 as we know it. On top of pure ES5, private symbols > make a lot of sense. In ES5+class-with-private-syntax, I'm much more > skeptical. Actually experience with a number of languages. But like I said, there is no ES5+class-with-private-syntax so I don't see how that is a useful argument. > > Also, private syntax as private symbol makes the proxy story complicated [1], > because the class or its instances need to publicize private symbols so that > proxies can add them to their whitelist when wrapping class instances. I > don't think leaking abstraction is a valid option, so it means that only 2 > out of the 3 following can be kept in the language: I don't have a problem at all with making the proxy story more complicated. Proxys are an expert feature designed for some specific use cases. they are probably an attractive nuisance. I would advise most JS programmer that if they are going down the road of using a Proxy, they are probably making a mistake. In that light, placing the extra complexity within the Proxy story seems just fine. > 1) proxy-wrapping class instances (without leaking abstractions) > 2) private syntax in class > 3) private symbols > We can probably predict in advance that JavaScript authors will largely not > want to give up on 2) (even if it comes only in ES7). Should 1) or 3) be > given up? Unless relevant use cases different than class-like usages are > provided, 3) can disappear in my opinion. If the above was the only choice (and I don't think it is) I would probably pick #1 to eliminate. Allen > > David > > [1] https://mail.mozilla.org/pipermail/es-discuss/2013-January/028285.html > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
