New: proposal-class-modifiers

[Ranando King]

@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 <isiahmeadows at gmail.com> 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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181202/22ba60d0/attachment-0001.html>