Le 29/04/2013 00:32, Mark S. Miller a écrit :
On Sun, Apr 28, 2013 at 2:33 PM, David Bruant <[email protected]
<mailto:[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:
|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?
ooooooohh.... Yes it does. I hadn't thought of WeakMaps for the private
syntax.
Sounds good then.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
