Default placement of instance properties (prototype vs. instance)

[tc39]

Default placement of instance properties (prototype vs. instance)

[bakkot]

I agree there's a typo in the spec text; both O and F there are unbound and should instead be receiver. You're correct that the intent is for fields to be defined on instances.

---

If the fields are only defined on the instance, then the parent class has no way of knowing about them in the constructor.

Fields are installed before the body of the constructor executes (or at the start of the super call in the case of derived classes): in other words, they're already present on this by the time it's possible to refer to this. So your example would work fine, I think, and end up with garfield.name === 'Garfield'.

In any case, this has been discussed at length already in tc39/proposal-class-public-fields#59. Ultimately, putting fields on the prototype seems likely to do more harm than good, even if there are use cases for it.

[mbrowne]

Thanks for the explanation. Ah, so in this proposal, the properties are initialized before the call to super()? I thought the declaration of Cat above was equivalent to this:

class Cat extends Entity {
  constructor(attributes) {
    super(attributes)
    this.name = null
  }
}

This is also the only way to transpile it to ES6 with conventional class syntax, since you can't do this.name = null before calling super()...it's how Babel currently does it. And in this version garfield.name === null.

But if the real implementation will do this behind the scenes somehow:

class Cat extends Entity {
  constructor(attributes) {
    this.name = null
    super(attributes)
  }
}

Then yes, that would solve it.

Alternatively (or in addition), maybe there could be some methods on Reflect that would have access to instance property definitions prior to the call to super().

[bakkot]

Sorry, I'm mistaken, instance fields on subclasses are initialized after the call to super exits, not when it enters. So you're right, that wouldn't work.

[ljharb]

It kind of seems like your assignAttributes implementation is brittle; specifically for this reason. Typically I'd expect these attributes to all be stored in an object or Map that's under a single property on this.

[mbrowne]

I think it's reasonable to want to implement this idiom as written...basically the idea is to create a plain old JS object but with the ability to set all the parameters at once in the constructor - and ignoring any extraneous properties that might be passed in. I'm not sure how using an object or Map would help with this particular problem, unless you mean passing the attribute map as an argument to the constructor like this:

class Entity {
  constructor(attributes) {
    this.attributes = attributes;
  }
}

class Cat extends Entity {
  static initialState = {
    name: null
  }
  
  constructor(attributes) {
    super({...Cat.initialState, ...attributes})
  }
}

...but that defeats the purpose of using a base class to assign the attributes (which was intended to reduce boilerplate code). And it allows invalid attributes to be added to the object. So I guess I'm just not following you.

Anyway, this is just one use case for wanting to reflect on instance property names. I can imagine other potential scenarios...for example, if you had a constructor with required parameters, with the current proposal the only way you could find out the property names from outside the class would be to actually create an instance (requiring specific knowledge of how to call that particular constructor).

But there are many ways to accomplish reflection, and I take your point that defaulting to putting properties on the prototype could be problematic. So perhaps I should close this issue and file a new one specifically about reflection.

[mbrowne]

Closed in favor of #36.