New: proposal-class-modifiers

Isiah Meadows isiahmeadows at
Sun Dec 2 21:43:12 UTC 2018

For `abstract`, I could see that being three things:

- Throw a reference error if an abstract method is called with no concrete
- Throw a type error if the constructor is called without its abstract
methods implemented
- Throw a type error if a subclass fails to implement all remaining
abstract methods and is not itself abstract

Each of these could be reasonably tacked on at the end.

For `final`, you'll need to create a way to block all means of
`Object.create`, with class constructors being the sole exception. That
complicates the mechanism tremendously, since prototype-based inheritance
alone can't enforce this unless you make `Object.setPrototypeOf(obj,
parent)` no longer directly equivalent to `obj.[[Prototype]] = parent`.
On Sun, Dec 2, 2018 at 16:28 Ranando King <kingmph at> wrote:

> Object.create and Object.setPrototypeOf operate on a different level than
> what I'm targeting. I can conceive of a means to make even these functions
> respect these tokens. However, if I were going to do that, I'd want these
> tokens to be applicable to objects and functions directly.
> Reflect.construct is essentially part of the process for `new` and would be
> required to respect these tokens. I'm still open on how far the effect of
> these tokens should extend.
> On Sun, Dec 2, 2018 at 3:20 PM Isiah Meadows <isiahmeadows at>
> wrote:
>> How would this interop with `Object.create`, `Reflect.construct`, and
>> `Object.setPrototypeOf`?
>> On Sun, Dec 2, 2018 at 16:16 Ranando King <kingmph at> wrote:
>>> This proposal is intended to add `abstract` and `final` to `class`
>>> definitions so as to modify the inheritability of a class.
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list