On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
> On Thu, Sep 29, 2011 at 17:08, Bob Nystrom <[email protected]> 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.
>>
>> attack(target) {
>> log(Monster.attackMessage);
>> }
>>
>> get isAlive() {
>> return this.health > 0;
>> }
>>
>> set health(value) {
>> if (value < 0) throw new Error('Health must be non-negative.')
>> this.health = 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;
Object.seal(this);
}.prototype.{
get x() { ... },
prop: 42,
method() {}
}.constructor.{
/* 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.
/be_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
