class-private syntax in ES6 (was: ES6, ES7, ES8 and beyond. A Proposed Roadmap.)

David Bruant bruant.d at gmail.com
Sun Apr 28 14:33:22 PDT 2013


Le 21/04/2013 19:22, Brendan Eich a écrit :
> At JQueryUK, I threw up a sketch in slides based on 
> http://wiki.ecmascript.org/doku.php?id=strawman:relationships:
>
> |class  SkinnedMesh extends  THREE.Mesh{
>   private  identityMatrix,
>           bones,
>           boneMatrices;
>
>   constructor(geometry,  materials)  {
>     super(geometry,  materials);
>
>     this at identityMatrix=  new  THREE.Matrix4();
>     this at bones=  [];
>     this at boneMatrices=  [];
>     ...
>   }
>
>   ...
> }|
Can you provide more details on the semantics of syntax given the 
relationship strawman?
With my understanding of the current proposal:
* in "this at bones =  [];", 'bones' has to be a string or (unique) symbol. 
I imagine the private syntax makes it a symbol (that will not be access 
beyond the class scope) for the sake of non-forgeability.
* by default, objects have no value for @geti nor @seti [1], so 
following the strawman, "this at bones =  [];" should set the value for the 
symbol. Unfortunately, (unique) symbols are enumerated via reflection, 
so this is not private.

Sharing my thoughts trying to figure out the semantics you want to provide:
Was it implicit that each class declaration creates a @geti/@seti pair 
as I describe at [2] and attach it to SkinnedMesh.prototype?
Hmm... if the pair on the prototype, then it can be shadowed by an 
outsider via Object.defineProperty. I believe this shadowing will give 
access to the symbol that was supposed to remain encapsulated any time 
the @-syntax is used and break privacy. So no prototype.
So the last chance is for the class @geti/@seti pair to be assigned as 
own property to each instances. And preferably make them 
non-configurable/non-writable properties so they remain where they are. 
One pair of property per instance may have a cost, but it sounds 
possible to heavily optimize in memory frozen properties of the same 
class for the 80% use case.
Even as own property, I believe inheritance can be made worked out (a 
class extending another accesses the inherited class @geti/@seti pair 
and builds its own pair on top of that. Well-encapsulated symbols won't 
collide from one class to another).

Was it what you had in mind?


> |class  Point{
>   constructor(private x, private y) {}
>   add(other) {
>     return Point(this at x + other at x, this at y + other at y);
>   }
>   ...
> }
> |
I'm guessing explanations to the above will lighten up my understanding 
of this part, but in case there is something non-trivial to explain 
here, I'll take it too.

Thanks,

David

[1] Last answer to Tom of 
https://mail.mozilla.org/pipermail/es-discuss/2013-April/029697.html
[2] Last answer to Tom of 
https://mail.mozilla.org/pipermail/es-discuss/2013-April/029700.html


More information about the es-discuss mailing list