Hi Christian
On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider
<cschn...@cschneid.com> wrote:
>
> Am 25.04.2021 um 05:47 schrieb Larry Garfield <la...@garfieldtech.com>:
> > In practice, I think all of the use cases for sealed classes are ADT-esque.
> > As I noted before, combining sealed classes with Nikita's
> > new-in-expressions RFC would allow for this (also using my short-functions
> > RFC for this example, although that's a nice-to-have):
> >
> > sealed class Maybe permits Some, None {
>
> ...
>
> > }
> >
> > final class None extends Maybe {}
>
>
>
> This is exactly the thing I'm worried about.
>
> Say I want to add something like logging to the None type.
> Now your sealed and final classes prevent me from defining MyNone extending
> None even though it would be 100% compatible with None. Just because *you*
> deemed that useless or wrong.
The point of sealed type is to fix the number of subclasses a given
type can have, which means you can handle a value by type (as that
list is not finite). Code that handles Optional values could look like
this:
```
if ($option instanceof Option\None) {
throw new Exception();
}
// We now know the value is a Some
var_dump($option->value);
```
If you suddenly provide your own version of None the code above will
break. This is probably more obvious when you look at the
enum-equivalent.
```
enum Option {
case None;
case Some($value);
}
```
To most people it's obvious that you can't add new cases to an
existing enum. It doesn't sound sensible to add logging to a data
class. That's something that belongs into a hook or service of some
kind.
People might also want to use sealed for behavioral classes, the use
case here is the same as final. Final is not here to make your life
harder. It's here to make the lives of the library maintainers easier.
If they have to reason about every way a method could be overridden,
every change in the library would become more risky, require more
thought and more frequent major version updates. This means more work
and less features for you, too.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
