Sep 27 meeting notes

Bob Nystrom rnystrom at
Fri Sep 30 10:12:54 PDT 2011

On Thu, Sep 29, 2011 at 6:20 PM, Brendan Eich <brendan at> wrote:

> On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
> On Thu, Sep 29, 2011 at 17:08, Bob Nystrom <rnystrom at> wrote:
> class Monster {
>   constructor(, {}
> I <3 this. It beats the (public name, public health) variant in my view by
> being explicit and not dragging in p-words.

Yeah, me too. The big win for me here is that I find this confusing:

class Point {
  constructor(public x, public y) {
    x = 2; // is this valid? does it assign to this.x or just the local
argument variable?

Using this.x in the constructor parameter list maintains a consistent
"always use this. to assign to object properties", which I like.

> This is great, and I'm still a sections fan, but they mix badly if there
> are any hints or smells of object literal data property initialiser synax.

Right. Personally, I'm not a fan of mixing object literal style into classes
(though I see the appeal from a unification perspective). Maybe that's just
my long C++/C#/Java habits.

> You (Bob) dodge that by using let, Oliver used var (and IIRC Bob started
> with var; so did ES4)

Yup. I actually prefer "var" slightly though I understand it gives Mark
hives (and for good reason). I don't really have much of a keyword
preference here at all as long as it's really short. Could be "thing" for
all I care. :)

-- however, Oliver and ES4 by fiat put data properties on the instance,
> methods on the prototype.

That feels a little... non-orthogonal? to me. Inside a class when you're
defining some property, there's two things you need to specify:

1. What flavor of property it is: function, constant, field, etc.
2. What object it gets defined on: constructor, prototype, instance.

Mixing those together so that 1 determines 2 feels kind of arbitrary and not
as flexible. I like the idea of the grammar informing one and sections
informing 2. Maybe that's just me.

> Separately, and a while ago, Alex pointed out that mutable prototype data
> properties, e..g let attackers = []; in this Monster example, are a footgun.
> People fail to shadow and mutate a shared singleton.

Yeah, I worry about that too, though I'm leery of giving up generality to
dodge that. (People complain as it is that class syntax is too rigid.)

> So why do we need declarative syntax for data properties on the prototype
> at all? Data properties on prototypes are exceedingly rare and usually a
> bug.

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

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.


- bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list