@Logan If this helps explain my stance, I'm skeptical of the use, and it really disrupts the consistency of JS's object model quite a bit. It makes sense to enforce at a static level, but not really at a dynamic runtime level. Also, this is lacking precedent in other dynamic languages with classes: Python, Ruby, Smalltalk, Lua, Io, and pretty much every other dynamic language with class- or prototype-based inheritance (that wasn't made for the JVM) doesn't support final classes. Python (IIRC through a decorator) and Ruby support abstract methods, but not final classes/methods.
----- Isiah Meadows [email protected] www.isiahmeadows.com On Sun, Dec 2, 2018 at 5:10 PM Logan Smyth <[email protected]> wrote: > > Wouldn't it be better `abstract`'s `target.prototype === newTarget.prototype` > check to be `target === newTarget`? It's not really the prototype that is at > issue here, it is the class constructor itself. It would not be good if you > could sidestep `abstract` by taking the prototype from the class and making a > new constructor for it. > > For `final` is it worth throwing an `extends` time vs just throwing when the > class is instantiated? It seems like `final` would otherwise require new > private state on the constructor itself, where otherwise it would essentially > just be the negation of the check `abstract` was doing already. > > Also, if those make sense, what do we gain by having these be keywords > instead of decorators? > > On Sun, Dec 2, 2018 at 1:43 PM Isiah Meadows <[email protected]> wrote: >> >> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
