Discuss
  • How to refer to the current prototype of a class.

How to refer to the current prototype of a class.

# /#!/JoePea (8 years ago)

Currently we use

class Foo {

  bar() {

    // we want the current prototype's (HomeObject's?) `baz` method, not
the leafmost prototype's (this') `baz` method.
    Foo.prototype.baz()

  }

  baz() {
    // ..
  }

}

What about a shorthand keyword like current for the "current prototype"?

class Foo {

  bar() {

    // we want the current prototype's (HomeObject's?) `baz` method, not
the leafmost prototype's (this') `baz` method.
    current.baz()

  }

  baz() {
    // ..
  }

}

What about prototype, because that word is, afterall, owned by JavaScript (though more likely to break code than current).

class Foo {

  bar() {

    // we want the current prototype's (HomeObject's?) `baz` method, not
the leafmost prototype's (this') `baz` method.
    prototype.baz()

  }

  baz() {
    // ..
  }

}

Or, since HomeObject is a thing, maybe a home keyword would be intuitive, although that is also more likely to break existing code than current?

class Foo {

  bar() {

    // we want the current prototype's (HomeObject's?) `baz` method, not
the leafmost prototype's (this') `baz` method.
    home.baz()

  }

  baz() {
    // ..
  }

}

Or a symbol?

class Foo {

  bar() {

    // we want the current prototype's (HomeObject's?) `baz` method, not
the leafmost prototype's (this') `baz` method.
    #.baz()

  }

  baz() {
    // ..
  }

}
# Michał Wadas (8 years ago)

this.constructor.prototype.baz

# Claude Pache (8 years ago)

Le 31 juil. 2016 à 05:12, Michał Wadas <michalwadas at gmail.com> a écrit :

this.constructor.prototype.baz

No, that is the prototype of the class of the object, which may reasonably be a subclass (and which can be anything in the most general cases).

What is the issue with just Foo.prototype?

# /#!/JoePea (8 years ago)

On Sun, Jul 31, 2016 at 4:15 AM, Claude Pache <claude.pache at gmail.com>

wrote:

What is the issue with just Foo.prototype?

​It means it is subject to renaming (therefore mistakes) when the class name needs to be changed. Also, consider how lengthy it is to access a getter or setter:

            Object.getOwnPropertyDescriptor(Foo.prototype,
'someSetter').set.call(this, value)
```​

vs

```js
current.someSetter = value

Having such a keyword for convenience may also encourage class designers to avoid the Fragile Base Class Problem.

# /#!/JoePea (8 years ago)

Having such a keyword for convenience may also encourage class designers

to avoid the Fragile Base Class Problem.

Maybe not to avoid the fragile base class problem per se, but it would be easier to express using the current prototype method (on current) versus the leaf-most subclass method (on this), and it would ideally be dynamic so that current would depend on where the method is located when it is called (it could be borrowed from another object).

As for super, what's wrong with just using Object.getPrototypeOf(Foo.prototype)? Well, it's a hard reference, but the fact that super is static doesn't make it any more useful. If super (and something like current) were dynamic instead of static, then they would be nice alternatives to using direct references to a class (f.e. Foo) because the methods would be borrowable, whereas using a reference to a class (like Foo) is just as static as the current super is, sosuper really doesn't add anything to the language except we can replace Object.getPrototypeOf(Foo.prototype) with super which is simple shorter to write, but it leaves the method non-borrowable so it doesn't improve the functionality of the language. super being dynamic would be a functional improvement to the language rather than a mere syntax sugar for Object.getPrototypeOf(Foo.prototype).

The same would apply to current, or whatever it would be named if it were a thing.