On Sun, Apr 28, 2013 at 2:33 PM, David Bruant <[email protected]> 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@identityMatrix= new THREE.Matrix4(); >> this@bones= []; >> this@boneMatrices= []; >> ... >> } >> >> ... >> }| >> > Can you provide more details on the semantics of syntax given the > relationship strawman? > With my understanding of the current proposal: > * in "this@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 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@x + other@x, this@y + other@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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
