Question 52098 in Javascript Question posted in
A very good W3school tutorial can be found here.

Why do instance fields belong to the instances instead of their prototype? – Javascript

In the JavaScript class syntax introduced in ES6 (static properties are accessible from the class, instance properties are accessible from the instances):

  • static fields belong to the class;
  • static methods belong to the class;
  • instance methods belong to the instances’ prototype;
  • this properties belong to the instances.

So I expected that instance fields would belong to the instances’ prototype, like instance methods. But that’s not the case, they get a special treatment and belong to the instances instead, like this properties.

For example, the class

class A {
  static x;                   // static field
  static f() {}               // static method
  y;                          // instance field (special treatment)
  g() {}                      // instance method
  constructor() {this.z = 0}  // this property
}

gives the results

> Object.getOwnPropertyNames(A)
[ 'length', 'name', 'prototype', 'f', 'x' ]
> Object.getOwnPropertyNames(A.prototype)
[ 'constructor', 'g' ]
> Object.getOwnPropertyNames(new A)
[ 'y', 'z' ]

Why do instance fields belong to the instances instead of their prototype?

A drawback that I see with this special treatment is that it prevents one from simply declaring non-function properties in the instances’ prototype, forcing one to do it after class declaration (or resort to a static initialization block):

> A.prototype.y2 = 0;
0
> Object.getOwnPropertyNames(A.prototype)
[ 'constructor', 'g', 'y2' ]

Another drawback is that if one wants to declare properties on the instances, there is already this for that, so it duplicates an existing language feature.

Tags:

2

Answers


  1. 0

    class syntax was just a syntactic sugar for existsing things:

    1. A prototype – an object with things shared between instances, mostly methods and get-set descriptors
    2. A constructor – a function to make objects with predefined prototype
    3. Using constructor as a namespace to keep related things
    4. Fields? What fields? You just have an object with prototype, do whatever you want with it

    class syntax included all that… with exception of constants on prototype – they have very weird behaviour (actually being property initializers) and noone really ever used them

    Login or Signup to reply.
  2. 0

    Prior to the addition of public instance fields, those properties had always belonged to the instances (except in some rather obscure usage). And after the addition, they kept storing those properties in the instances.

    In section 2.1 of this article by Dr. Axel Rauschmayer, it shows the motivation for adding public instance fields.

    Sometimes, you have an assignment in a constructor that creates an instance property, but is not influenced by any other data in the constructor (such as a parameter)

    class MyClass {
  constructor() {
    this.counter = 0;
  }
}

    In such a case, you can use a field to move the creation of counter out of the constructor:

    class MyClass {
  counter = 0;
  constructor() {
  }
}

    So, the addition of public instances can simplify constructors. It also makes it clear that the initial value of a property does not depend on the arguments of the constructor. (It may also help readability and make it easier for documentation)

    There is also a semantic difference, as class fields use the [[DefineProperty]] semantics (with a behavior that matches Object.defineProperty), so with public fields, the setter in a superclass will not be called.

    Compare:

    class A {
  set prop(value) {
    console.log('SETTER: '+value);
  }
}
class B extends A {
  constructor() {
    super();
    this.prop = 123; // (setter will be called, inherited from A)
  }
}
console.log(new B); //does not contain a 'prop' field because there is a setter

    with

    class A {
  set prop(value) {
    console.log('SETTER: '+value);
  }
}
class B extends A {
  prop = 123; //setter from A is not called
}
console.log(new B);

    As for why those properties belonged to the instances rather than prototypes (also applicable in the days before classes became a thing in JS):

    If you have a property in the prototype, once you assign, say, instance1.property1 = 3, the value from the prototype is no longer used (property shadowing); a new property is created in the instance and the value in the prototype is not changed. So putting a value in the prototype is not very useful.

    In contrast, a method is usually not re-assigned, and it’s useful to share between instances. instance1.method1(...) and instance2.method1(...) call the same function with different this. (So those are not aliases of each other as they have different effects).

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search