Sep 27 meeting notes

Brendan Eich brendan at mozilla.com
Fri Sep 30 10:56:32 PDT 2011


On Sep 30, 2011, at 7:12 PM, Bob Nystrom wrote:

> We want a syntax for properties on the constructor, so is it worth it to specifically forbid that notation outside of the class: section?

It's future-proof. Rather do less and get it right than over-reach and regret the stuff that we got wrong.


> If we did want to go down the path of a more rigid class pattern (i.e. no data props on prototype, etc.) then I think we could support all of the combinations we care about with a pretty terse notation:
> 
> class Point extends SomeBaseClass {
>   // Constructor.
>   constructor(this.x, this.y) {
>     class.lastPoint = this;
>   }
> 
>   // Constant on class.
>   const ZERO = new Point(0, 0);
> 
>   // Data property on class.
>   var lastPoint = undefined; // or let
> 
>   // Function on class.
>   class add(a, b) {
>     return a.add(b);
>   }
> 
>   // Nested class (data property on class whose value is a class).
>   class Foo {
>     ...
>   }
> 
>   // Constant on prototype: not supported
>   // Data property on prototype: not supported
> 
>   // Function on prototype.
>   add(other) {
>     return new Point(this.x + other.x, this.y + other.y);
>   }
> }
> 
> This gets rid of sections, and gets rid of "static" by using "class" instead. It avoids the "class class" problem for nested classes by declaring by fiat that a nested class goes on the constructor.
> 
> Thoughts?

I like that nested class is "static" or rather, a property of the outer class's constructor.

This has the irregularity you objected to in the ES4/Oliver "data properties on instances, methods on prototype", but with data properties on the class instead of the instance.

And this is future-hostile to data properties on the prototype, something you're right to consider supporting. Using a class: section is future-friendlier and not much of a hardship.

Try this:

class Point extends SomeBaseClass {
  // Constructor.
  constructor(this.x, this.y) {
    class.lastPoint = this;
  }

class:
  // Constant on class.
  const ZERO = new Point(0, 0);

  // Data property on class.
  var lastPoint = undefined; // or let

  // Nested class (data property on class whose value is a class).
  class Foo {
    ...
  }

prototype:
  // Function on class.
  class add(a, b) {
    return a.add(b);
  }

  // Constant on prototype: not supported
  // Data property on prototype: not supported

  // Function on prototype.
  add(other) {
    return new Point(this.x + other.x, this.y + other.y);
  }
}

Supporting a prototype: label to allow alternation for minimal change under maintenance is plausible.

For now I think we should minimize and future-proof by forbidding data declarations in the prototype section (the default, implicit section without any label).

/be



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110930/126bec92/attachment-0001.html>


More information about the es-discuss mailing list