Sep 27 meeting notes

Brendan Eich brendan at
Thu Sep 29 18:20:52 PDT 2011

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.

>>   attack(target) {
>>     log(Monster.attackMessage);
>>   }
>>   get isAlive() {
>>     return > 0;
>>   }
>>   set health(value) {
>>     if (value < 0) throw new Error('Health must be non-negative.')
>> = value
>>   }
>>   let numAttacks = 0;

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. You (Bob) dodge that by using let, Oliver used var (and IIRC Bob started with var; so did ES4) -- however, Oliver and ES4 by fiat put data properties on the instance, methods on the prototype.

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.

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.

>> class:
>>   const attackMessage = 'The monster hits you!';

In contrast, constants on constructors are common, and we can define them before any possible use with this desugaring:

const Derived =
  Base <| function(x) {
    this._x = x;
    get x() { ... },
    prop: 42,
    method() {}
    /* class consts and methods go here */
    #attackMessage: "The monster hits you!"

I mashed up the Monster class const with the Derived example and used the meeting's consensus meaning of # on data property making it non-configurable and non-writable.

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

More information about the es-discuss mailing list