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) {

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) {

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]].


es-discuss mailing list

Reply via email to