New: proposal-class-modifiers

[Isiah Meadows]

@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
contact at isiahmeadows.com
www.isiahmeadows.com

On Sun, Dec 2, 2018 at 5:10 PM Logan Smyth <loganfsmyth at gmail.com> 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 <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