Sep 27 meeting notes

[Bob Nystrom]

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

> On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
>
> On Thu, Sep 29, 2011 at 17:08, Bob Nystrom <rnystrom at google.com> wrote:
>
> class Monster {
>
>   constructor(this.name, this.health) {}
>
>
> 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.

Thoughts?

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