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

David Bruant bruant.d at gmail.com
Sun Apr 28 15:42:46 PDT 2013


Le 29/04/2013 00:32, Mark S. Miller a écrit :
>
>
>
> On Sun, Apr 28, 2013 at 2:33 PM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     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?
>
>
> Hi David, I'll be brief because I have little time today. And I 
> probably won't follow up on any responses until another day -- just so 
> you'll know. But you drifted quite far from what the relationship 
> strawman has in mind. The example above would act approximately as if 
> written
>
>
> let SkinnedMesh = (function(){
>     const identityMatrix = WeakMap();
>     const bones = WeakMap();
>     const boneMatrices = WeakMap();
>
>     function SkinnedMesh(geometry,  materials) {
> THREE.Mesh.call(this, geometry,  materials);
> identityMatrix[@seti](this, new THREE.Matrix4());
> bones[@seti](this, []);
> bonesMatrices[@seti](this, []);
>         ...
>     }
> SkinnedMesh.__proto__ = THREE.Mesh; // more on __proto__ later
>     SkinnedMesh.prototype = Object.create(THREE.Mesh.prototype);
>     ...
>     return SkinnedMesh;
> }).call(this);
>
>
> Where "WeakMap" may be renamed something more intuitive for this role. 
> Does this clear things up?
ooooooohh.... Yes it does. I hadn't thought of WeakMaps for the private 
syntax.
Sounds good then.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130429/c4c38faf/attachment.html>


More information about the es-discuss mailing list