Proposal About Private Symbol

Rick Waldron waldron.rick at
Sat Dec 20 10:04:19 PST 2014

On Sat Dec 20 2014 at 7:54:19 AM Gary Guo <nbdd0121 at> wrote:

> I have just sent this proposal through
> but
> I don't know what more I need to do. I am a high school student from China
> who is interested in next-generation ecmascript and has been working on an
> ecmascript implementation for months.

That's excellent!

> Since I am not a native speaker, there might be grammar mistakes in
> following texts. I have sent this proposal to this mailing list this about
> 8 hours ago but to some reason it is not delivered.

Sometimes the "spam" mail trap is too aggressive, but glad to see this came

> Here is my proposal:
> As known, Symbol Type introduced in ECAMScript provides a way to create
> private fields,

This is misunderstood, Symbol creates a unique, non-string value that may
be used as a property key. There is nothing about Symbol instances that
makes them private—only unique. Private "things" were deferred to ES7.

> and feature extensions without interfering with current usage, since each
> Symbol created is unique. However, sometimes software developers may not
> want to expose a private field to public, so they might not want to let the
> symbol to be easily accessed from Object.getOwnPropertySymbols function.
> A change to the current Symbol constructor can be made to change this
> situation. Instead of using Symbol([Description]), we may use
> Symbol([Description], [Private]).

> When the private parameter is set to true, the symbol will be eliminated
> from Object.getOwnPropertySymbols. In later text, I will call such a Symbol
> private symbol.
> This change will not only benefit developers, but also helps to clarify
> the standard. The ECMAScript 5.1 uses internal properties, while the
> ECMAScript Harmony uses internal slots as a way to define the properties
> that are not public accessible but exists in an object. However, this adds
> to the difficulty of implementing such objects with internal
> properties/slots. If private symbol is supported by the implementation, the
> implementation can simply just create a property of that object, with
> property key a private symbol. For example, we can say there is a private
> well known symbol (that is not exposed to user code)
> Symbol([[BooleanData]]), and we can eliminate the description about
> internal slot and express texts in a more uniform way.
> This also allows more standard-defined objects to be implemented in
> ECMAScript itself, by only exposing these private symbols to certain
> ECMAScript modules that implement features required by the Standard. I uses
> the way that describes below to implement my own ECMAScript implementation.
> For example:
> ```js
> // PrivateSymbol.js
> var BooleanData = Symbol("[[BooleanData]]", true);
> export {BooleanData}
> // Boolean.js
> import {BooleanData} from 'PrivateSymbol.js'
> var global=this;
> global.Boolean = function(x){
>     if(this==global){
>         return !!x;
>     }else{
>         this[BooleanData]=!!x;
>     }
> }
> // User Code
> var b=new Boolean(true);
> b["[[BooleanData]]"] → undefined // guaranteed by semantics of Symbol
> b[Symbol("[[BooleanData]]")] → undefined // guaranteed by semantics of
> Symbol
> b.getOwnPropertySymbols() → [] // guaranteed since Symbol is private
> ```
> So there is still no way to access or modify its [[BooleanData]] property,
> so the property is equivalent to internal slots/properties, while the way
> to describe them is uniformed.

Similar proposals have been made in the past:

(Beginning at and evolving through...)

Ultimately it was decided that Symbol is just a symbol and that "private"
things will be dealt with orthogonally (and at a later date).

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

More information about the es-discuss mailing list