@Logan > It would not be good if you could sidestep `abstract` by taking the prototype from the class and making a new constructor for it.
That's precisely why it's a prototype test and not a constructor test. Everything that defines the initial "shape" of the class is on the prototype. The constructor only comes into play after a new object has been created with the corresponding prototype attached. If the prototype of the constructor being called matches the prototype of newTarget, and that prototype has been flagged as abstract, the new object creation is halted immediately. Constructor comparisons can easily be spoofed simply by Proxying the constructor. Where target would be the un-Proxied constructor, newTarget would be the Proxy. They wouldn't match so the abstract test would fail and an object would be constructed. Contrary to what you may have been led to believe, the definition of a class is its prototype. There are those who refuse to accept this reality, and that's fine. But if you make the wrong assumptions as a result of an incorrect understanding, the results won't turn out how you want. With `final`, the point is that a `class` that extends from a `final class` ***cannot be defined***, not simply "cannot be instantiated". Even without instantiating, a defined `class` can still be used. >...it would essentially just be the negation of the check `abstract` was doing already. That's precisely correct. These 2 new tokens are the polar opposites of each other. One restricts construction to cases where the prototypes of `target` and `newTarget` match (`final`), while the other requires that they don't match (`abstract`). That's also the reason they cannot be used together. @Isiah Sounds like part of what you're looking for is abstract methods rather than an `abstract class`. I wasn't targeting that. If I were, that would be something to add to proposal-common-class-modifiers. If I were to look at what you're describing more holistically, you're looking for "interface", a way to set up a contract for what's supposed to be there and require it all to be present. I wasn't targeting that either. In fact, that would probably be a good proposal all by itself. I'll give an implementation for that some thought. However, with this proposal, all I'm thinking about is inheritance constraints. As for `final`, I need you to convince me that it's worth while preventing Object.create and Object.setPrototype. It's shouldn't be that difficult to do, but I don't have an understanding of why you'd want to. Especially when you consider that when some form of private goes in (assuming it's not Symbol.Private) class instances will be quite a bit different than vanilla objects. I get that `final` is something not seen in dynamic languages (outside the JVM), but it is a useful tool in giving developers control over how their code can be used. Isn't that part of the point of trying to implement private data in ES? On Sun, Dec 2, 2018 at 4:19 PM Isiah Meadows <[email protected]> wrote: > @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
