Le 20/01/2013 18:54, Allen Wirfs-Brock a écrit :
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.
Secure private communication between friend objects can be achieved
simply and efficiently with functions or weakmaps already. Why is there
a need for an additional construct for that use case?
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.
Will we ever? If the answer is yes, my point stands. TypeScript has
private syntax in class. People want it. The ES6 cut-off was too short
for TC39 to settle on private in class, but the pressure is here so it's
going to happen sooner or later (Mark was saying ES7).
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.
Does defining how it works at the object model level commits the
language to expose a runtime construct allowing to use the lowest-level
feature directly?
I think it does not. You think it does, hence private symbols:
* For which benefits?
* One downside is that it brings along more complexity to the
language... well... to proxies at least. I understand and somewhat agree
with your argument that complexifying proxies isn't a problem, but at
least, there should be a benefit.
Also, given that private-in-classes aren't in ES6, why would it be
necessary to add private symbols in ES6? Until there is a feature that
demands to be desugared as private symbols (I don't think there is, but
you probably know better, so tell me if so), it might be wise to put
them on hold.
IMO and for reasons I've already presented, saying that private state is just
relationships defined via WeakMaps is a non-starter.
I disagree with your arguments on WeakMaps, because choosing to desugar
the syntax to WeakMaps doesn't commit neither the implementation nor the
spec to actually use weakmaps to spec or to implement the feature.
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.
There will be.
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.
"complicated" was an expression. Either proxies don't work with class
instances, making them vastly pointless or classes need to publicize
their private symbols (or maybe expose something like
"myClass.acceptProxy" which is marginally better), thus ruining their
own encapsulation.
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.
To the point of making proxies useless when interacting with class
instances or ruining class encapsulation?
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)
Which other choices do you think are available?
Davud
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
