On Jan 16, 2013, at 12:57 PM, Russell Leggett wrote:
> On Wed, Jan 16, 2013 at 3:48 PM, Brendan Eich <bren...@mozilla.com> wrote:
> Mark S. Miller wrote:
> My position on private symbols.
>
> My position on classes is and has always been that classes are worth
> introducing into the language*only* if they give us, or can be used
>
> with, an affordable means for true object encapsulation. Assuming
> Allen is right about what actual implementors will do (which I find
> plausible) then WeakMaps are not that means. Given other discussions,
> I am confident that the objects-as-closures pattern will not become
> efficient either -- it is likely to continue to cost an allocation per
> method per instance as its semantics naively suggests. So of the
> options practically on the table, I think private symbols are the only
> workable choice. If this is correct, then I consider private symbols
> to be a requirement. Am I missing anything?
>
> I agree, but David Bruant is arguing for weakmap-with-hint still, and Kevin
> is arguing (my summary) "YAGNI" to high-integrity privacy, not exclusively
> but for most developers -- and for the SES minority, weakmaps are enough.
>
> I think Kevin's argument is pretty strong. SES is definitely not everyone,
> and unique is pretty powerful, especially if you make the slot
> non-enumerable. The when in doubt... argument has been made. ES6 is pretty
> stuffed as it is. Thinking about ES7, though, I thought of a possibly
> interesting place that might be more fitting for private style slots.
>
> I've thought about the
> tradmark(http://wiki.ecmascript.org/doku.php?id=strawman:trademarks) proposal
> a lot, because I keep hearing the notion of a brand being used as a reason
> for a private symbol. Perhaps branding could be implemented with private
> symbols... *or* perhaps high-integrity privacy could be related with brand. A
> brand could open the door to ADT/typeclass/protocol style abstractions, and
> perhaps that is a better location for privacy.
I normally a behaviorist and don't care whether the contract compliant object
you pass me is one that I certifiably created or one you created. However, in
some situations being able to identify "trusted" objects is an absolute
requirement and in even more situations it is a perceived requirement. Being
able to identify such trusted object, is what I call branding. The poster
child that I hold up for this isn't SES (although it apparently does requiring
branding) but the DOM. The DOM designers really believe that most DOM objects
need to be branded in this manner.
An explicit goal of ES6 is to support self hosting of important native
libraries including the DOM. Self hosting libraries will be practical only if
the self hosted implementation can approach native performance and that
includes any overhead for branding, where it is required. In my previous
message I explained why we shouldn't expect WeakMap based branding, in
practice, to perform competitively with private Symbol based branding. If we
remove private Symbols from ES6 and assume that WeakSymbols aren't a perf
competitive solution then the only branding solution (for use cases like the
DOM) that I see remaining is something based upon using Proxies. But that would
mean that essentially every DOM object would have to be represented using a
Proxy but proxies themselves impose performance issues and currently (using
private Symbol branding) most DOM objects don't need to be proxies.
Private Symbols actually have very little impact upon the core ES specification
and presumably implementations. The only place they introduce any real
complications is in the semantics of proxies. And even there, the
complications are manageable. In fact, if I really wanted to conceptually
simplify ES6, I would look at eliminating or simplifying Proxy before I would
look to eliminate private Symbols.
Private Symbols are a good pragmatic engineering solution to a very real
problem. We really should move forward with them. I don't think we can wait for
ES7 .
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
