Hawt.
A bit rough in that LHS <& RHS mutates LHS, whereas LHS <| RHS is pure and
produces a new object (which could be optimized to mutate RHS, note well!).
Both <| and <& are operators, to support chaining. Would it be better for <& to
be pure as <| is, and make an assignment operator form, LHS <&= RHS, that
expands to LHS = LHS <& RHS?
Anyway, if I have <& right, then:
class SkinnedMesh extends THREE.Mesh {
constructor(geometry, materials) {
super(geometry, materials);
public identityMatrix = new THREE.Matrix4();
public bones = [];
public boneMatrices = [];
...
}
update(camera) {
...
super.update();
}
}
from http://wiki.ecmascript.org/doku.php?id=harmony:classes would desugar to:
function SkinnedMesh(geometry, materials) {
return super(geometry, materials) <& {
identityMatrix: new THREE.Matrix4(),
bones: [],
boneMatrices: [],
...
};
}
SkinnedMesh.prototype = THREE.Mesh.prototype <| {
update(camera) {
...
super.update();
}
};
Class-side inheritance could be done via
let SkinnedMesh = THREE.Mesh <| (function (geom, mats) { ... } <& {
classMethod() {...} });
This loses the hoisting of SkinnedMesh that the function declaration desugaring
gained "for free" -- another rough spot to smooth out.
There's still a usability argument for class syntax, certainly.
Class syntax is also, for some folks, an attractive nuisance because of
single-inheritance OOP being oversold and very often the wrong paradigm. But <&
helps there too -- one can more conveniently make mixins (I must mean <&= here,
of course).
The last conflicting name wins, or so it seems from what you've written. The
compositional answer there is to seal properties you don't want anyone to
redefine by a conflicting extend operation. I'm assuming the internal method
used to update the LHS or populate the new copy of it is [[DefineOwnProperty]],
as with ES5 object literals, and not [[Put]].
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
