Private Slots

Mark S. Miller erights at
Sat Jan 26 00:24:40 PST 2013

On Wed, Jan 16, 2013 at 3:53 PM, Allen Wirfs-Brock <allen at>wrote:

> On Jan 16, 2013, at 3:20 PM, Brandon Benvie wrote:
> > It's worth noting that private Symbols *are* used by the ES6 spec to
> solve a number of other problems currently. They are used to provide easy
> to use hooks for overriding builtin functionality: @@hasInstance, @@create,
> @@toStringTag, @@iterator, and @@ToPrimitive. Some of these (@@toStringTag,
> @@iterator) likely make sense as unique symbols, but the others protect
> access to powerful capabilities that should likely be protected. Without
> private symbols, it would be difficult to expose these APIs in the easily
> hookable manner they are provided now. Using prototypal inheritance along
> with private symbols to protect access is exactly how these hooks are made
> easy to use.
> >
> Let's refer to all of these built-in @@symbols as language extensions
> points.
> Upon my first reading of the above, I wasn't sure I agreed with Brandon.
>  After all, language extension point symbols all need to be publicly
> available (presumably via module imports)  if certain forms of extended
> abstractions are going to be defined by ES code.  From that perspective
> regular non-private Symbols should be fine for representing language
> extension points. (BTW, note I avoid saying "unique symbol" as that isn't
> current part of the ES6 vocabulary.  We have Symbols, some of which are
> private.  But all of them (including private Symbols) are unique values.)
> However, here is why it might make sense to make some of language
> extension points private:  If you are creating a sandboxed environment
> where you would like to limit the availability of some of the language
> extension points and hence the ability to define new abstractions with the
> extended functionality.   A sandbox's module loader can presumably restrict
> access to the modules that would export some or all of the language
> extension points.  However, if the language extension points are
> represented using regular, non-private Symbols then it still might be
> possible to discover the language extension points via reflection and then
> use them to circumvent the sandbox restrictions.  If they are represented
> as private Symbols this would not be possible.
> So that is a theoretical reason why  we might want language extension
> points to be private Symbols. But, in practice, it isn't clear to me why
> you would want to sandbox any of the currently identified language
> extension points in this manner.  They all have utility in defining
> application level abstractions.  That's why they're there. If you take them
> away you have a less powerful language.  It also isn't clear what potential
> hard is exposed by them.
> Does anyone have particular language extension points that they think need
> to be restricted in this manner?

Hi Allen, do you mean the symbols in table 10:



I see no reason for any of these to be private. Are there additional
language extension points I should look at?

> Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list