Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114134
MIME-Version: 1.0
References: <17903a93d74.120722efe200673.5873031933651438902@void.tn>
In-Reply-To: <17903a93d74.120722efe200673.5873031933651438902@void.tn>
Date: Sat, 24 Apr 2021 19:38:39 +0200
Message-ID: <CAPyj-LAm2ek4h=R_i+Y=Aey1bzHFJXNmHS2n9HnTH104H6zb_w@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Saif

On Sat, Apr 24, 2021 at 1:35 PM Saif Eddin Gmati <azjezz@void.tn> wrote:
>
> Hello Internals,
>
> I'm sending this email to open discussion about sealed classes, interfaces, and traits feature for PHP 8.1.
>
> I have create a Draft RFC here: https://wiki.php.net/rfc/sealed_classes
>
> A major concern for few people have been the syntax, in which it
> introduces 2 new keywords into the languages, therefor, i have added a
> section about alternative syntax which could be used to avoid this
> problem.

As mentioned off-list, I think there's some overlap with ADTs.
https://wiki.php.net/rfc/tagged_unions

There are two major motivations of sealed I can think of:

1. Usage in libraries for classes that can't be final because they're
extended by other internal classes. This prevents them from being
extended in user land and used in unintended ways, which reduces risks
of breaking changes.
2. For types have a fixed number of subtypes. This makes it possible
to handle a value by type and knowing that you've handled all possible
cases (exhaustiveness checks). Good examples are Option
(https://doc.rust-lang.org/std/option/enum.Option.html) or Result
(https://doc.rust-lang.org/std/result/enum.Result.html).

It could even be argued that 1 and 2 are the same. Enums/ADTs
essentially try to solve the same problem. This example is taken from
the RFC and rewritten as an enum:

```
enum Shape {
    case Circle;
    case Square;
    case Rectangle;
}
```

Obviously this is the simplest case, but enums/ADTs allow adding
arbitrary data to each case and arbitrary behavior to the enum itself.
This approach differs from sealed in a few ways:

* Sealed allows (or requires in terms of autoloading) separating
subtypes into multiple files
* The subclasses of sealed classes are allowed to have diverging APIs,
while methods in enums are currently only allowed on the enum itself.
This could be changed but feedback from the enum RFC has shown this is
not desired by most people.
* Sealed could be used for existing classes without breaking the API too much.
* The syntax for enums is much more concise
* For cases with no data enums will create a singleton, while sealed
will require manually managing a singleton or creating an instance for
each value (e.g. new Option\None).

There's probably more, these are just off the top of my head. This
begs a few questions:

* Are these approaches different enough to justify both of them?
* If not, which is the preferable approach?

Ilija