On Sat Dec 20 2014 at 7:54:19 AM Gary Guo <[email protected]> wrote:
> I have just sent this proposal through > http://www.ecma-international.org/memento/register_TC39_Royalty_Free_Task_Group.php > 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 through. > > 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...) - http://wiki.ecmascript.org/doku.php?id=strawman:names - http://wiki.ecmascript.org/doku.php?id=strawman:private_names - http://wiki.ecmascript.org/doku.php?id=strawman:unique_string_values Ultimately it was decided that Symbol is just a symbol and that "private" things will be dealt with orthogonally (and at a later date). Rick
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
