Class literals: does "public" still make sense?

Kam Kasravi kamkasravi at yahoo.com
Sun Sep 25 15:12:52 PDT 2011


Would the new private syntax then go from

(old syntax)
class Monster {
  // The contextual keyword "constructor" followed by an argument
  // list and a body defines the body of the class’s constructor
  // function. public and private declarations in the constructor
  // declare and initialize per-instance properties. Assignments
  // such as "this.foo = bar;" also set public properties.
  constructor(name, health) {
    public name = name;
    private health = health;
  }
 
  // An identifier followed by an argument list and body defines a
  // method. A “method” here is simply a function property on some
  // object.
  attack(target) {
    log('The monster attacks ' + target);
  }
 
  // The contextual keyword "get" followed by an identifier and
  // a curly body defines a getter in the same way that "get"
  // defines one in an object literal.
  get isAlive() {
    return private(this).health > 0;
  }
 
  // Likewise, "set" can be used to define setters.
  set health(value) {
    if (value < 0) {
      throw new Error('Health must be non-negative.')
    }
    private(this).health = value
  }
 
  // After a "public" modifier,
  // an identifier optionally followed by "=" and an expression
  // declares a prototype property and initializes it to the value
  // of that expression. 
  public numAttacks = 0;
 
  // After a "public" modifier,
  // the keyword "const" followed by an identifier and an
  // initializer declares a constant prototype property.
  public const attackMessage = 'The monster hits you!';
}

to:
class Monster {
  // The contextual keyword "constructor" followed by an argument
  // list and a body defines the body of the class’s constructor
  // function. public and private declarations in the constructor
  // declare and initialize per-instance properties. Assignments
  // such as "this.foo = bar;" also set public properties.
  constructor(name, healthvalue) {
    public name = name;
    module name from "@name";
    private health = name.create();
    this[health] = healthvalue;
  }
 
  // An identifier followed by an argument list and body defines a
  // method. A “method” here is simply a function property on some
  // object.
  attack(target) {
    log('The monster attacks ' + target);
  }
 
  // The contextual keyword "get" followed by an identifier and
  // a curly body defines a getter in the same way that "get"
  // defines one in an object literal.
  get isAlive() {
    return this[health] > 0;
  }
 
  // Likewise, "set" can be used to define setters.
  set health(value) {
    if (value < 0) {
      throw new Error('Health must be non-negative.')
    }
    this[health] = value
  }
 
  // After a "public" modifier,
  // an identifier optionally followed by "=" and an expression
  // declares a prototype property and initializes it to the value
  // of that expression. 
  public numAttacks = 0;
 
  // After a "public" modifier,
  // the keyword "const" followed by an identifier and an
  // initializer declares a constant prototype property.
  public const attackMessage = 'The monster hits you!';
}
?

If so it seems odd, privately named variables like health, although declared in the constructor are implicitly available throughout the class.


________________________________
From: Mark S. Miller <erights at google.com>
To: Brendan Eich <brendan at mozilla.com>
Cc: Kam Kasravi <kamkasravi at yahoo.com>; Axel Rauschmayer <axel at rauschma.de>; es-discuss <es-discuss at mozilla.org>
Sent: Sunday, September 25, 2011 2:37 PM
Subject: Re: Class literals: does "public" still make sense?


On Sun, Sep 25, 2011 at 2:08 PM, Brendan Eich <brendan at mozilla.com> wrote:

On Sep 25, 2011, at 1:04 PM, Kam Kasravi wrote:
>
>If the intent of classes is to provide a declarative syntax for its 'shape' then dropping the private syntax in lieu of private name objects seems to run counter to this philosophy. 
>
>We did not agree to drop the private declaration syntax at the July TC39 meeting. Perhaps my understanding of our agreement then does not match Marks?

It matches.
 

>
>What we agreed to drop was the private(this) straw syntax in the classes proposal, in favor of this[x], this[y], for private-declared private name objects x and y.

We definitely agreed to drop private(this) and private(other), as these were only ever placeholders for a needed syntax anyway. My own experience trying to use them is that they are unbearably verbose. We agreed to use the this[x] syntax *provided* it works out, depending on the price syntax and semantics of private names. Btw, I am optimistic it will work out. I just want to keep that qualifier on the table ;). 
-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110925/ffca6cee/attachment.html>


More information about the es-discuss mailing list