For `abstract`, I could see that being three things: - Throw a reference error if an abstract method is called with no concrete implementation - 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 <[email protected]> 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 <[email protected]> > wrote: > >> How would this interop with `Object.create`, `Reflect.construct`, and >> `Object.setPrototypeOf`? >> On Sun, Dec 2, 2018 at 16:16 Ranando King <[email protected]> wrote: >> >>> This proposal is intended to add `abstract` and `final` to `class` >>> definitions so as to modify the inheritability of a class. >>> >>> https://github.com/rdking/proposal-class-modifiers >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
