New: proposal-class-modifiers

[Logan Smyth]

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 <isiahmeadows at gmail.com> 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 <kingmph at gmail.com> 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 gmail.com>
>> 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 gmail.com> 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
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181202/78f6a6f7/attachment-0001.html>