On Sun, Apr 28, 2013 at 2:33 PM, David Bruant <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<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?




>
>
>
>  |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<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<https://mail.mozilla.org/pipermail/es-discuss/2013-April/029700.html>
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130428/4263d70c/attachment-0001.html>

On Sun, Apr 28, 2013 at 2:33 PM, David Bruant <bruant.d at gmail.com> wrote:

> 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@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


```js
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?