I noted some open issues on "Classes with Trait Composition"

Andreas Rossberg rossberg at google.com
Mon May 23 07:16:28 PDT 2011


On 20 May 2011 18:00, David Herman <dherman at mozilla.com> wrote:
> I think "modules are a construct that evaluates to an object" is the wrong way to think about them. Syntactic modules are a second-class construct that is not an expression. You can reflect on modules at runtime, and that reflection is provided as an object, but that's because almost all compound data structures in JS are objects. But I would advise against describing modules as a kind of object.
>
> And I think an important aspect of classes is that they are providing a declarative convenience for doing things that people *already* do with objects in JS today.

I see what you are saying, and yes, they are intended to serve a
different purpose. But they still share a lot of semantic overlap. And
I foresee that the overlap will increase overtime, as the language
evolves.

Take just one specific example: there already is the proposal for
extending modules with "module functions"
(http://wiki.ecmascript.org/doku.php?id=strawman:simple_module_functions)
-- which makes a lot of sense, is straightforward, and I'm sure that
people will demand something along these lines sooner or later. But
for better or worse, modules now actually have become classes!
Compare:

  class Point {
    private x, y
    constructor(x0, y0) { x = x0; y = y0 }
    public function move(dx, dy) { x += dx; y += dy }
    public function abs() { return Math.sqrt(x*x, y*y) }
  }

  let p = new Point(3, 4)
  p.abs()

with:

  module Point(x0, y0) {
    let x = x0, y = y0
    export function move(dx, dy) { x += dx; y += dy }
    export function abs() { return Math.sqrt(x*x, y*y) }
  }

  let p = Point(3, 4)  // assuming module functions are reflected into functions
  p.abs()

Almost the same effect, even though the underlying semantics differs
somewhat. You can even express simple inheritance with import and
export, depending on how general they will be in the end.

Obviously, there are aspects that you still cannot express with
modules but can with classes, and vice versa. But my point is that at
their core, they end up being pretty similar things. And their
differences might eventually start looking rather accidental. I would
feel better if we thought a bit harder about ways to utilize the
commonalities before we grow the size of the language too quickly.

/Andreas


More information about the es-discuss mailing list