---- On Sun, 25 Apr 2021 08:39:37 +0100 Olle Härstedt <[email protected]>
wrote ----
> > 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 {
> >
> > public const None = new None();
> >
> > static public function Some($x) => new Some($x);
> >
> > public function value() => throw new NotFoundException();
> >
> > public function bind(callable $c) => static::None;
> > }
> >
> > final class None extends Maybe {}
> >
> > final class Some extends Maybe {
> > private $val;
> > private function __construct($x) { $this->val = $x; }
> >
> > public function value() => $this->val;
> >
> > public function bind(callable $c) => new static($c($this->val));
> > }
>
> Yes, the Maybe/Option type is a good example! Because you know there
> will never be another extension. But it's worth noting that whenever
> you do *not* know that, these concepts suffer, even in functional
> programming, by the same issues as I mentioned before with regard to
> maintainability - you can't easily extend it without touching old code
> (there are attempts to fix this by making algebraic datatypes
> extensible, but it didn't get widely adopted AFAIK). Also see this
> thread about the expression problem:
> https://stackoverflow.com/a/871375/2138090
>
> Disregarding the limitations of maintainability, the real power of
> algebraic datatypes is of course the pattern matching functionality
> seen in OCaml and Haskell. I'm leaning towards tagged unions + pattern
> matching have more to offer PHP than sealed classes (and even more so
> when pattern matching can be extended with guard clauses and catching
> exceptions). The RFC author(s) might want to extend the RFC to reflect
> the relation to tagged unions, and how they overlap (or not)?
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
As mentioned in a previous email (
https://news-web.php.net/php.internals/114134 ), there's many differences
between ADTs and Sealed classes,
and in my opinion that's enough to have them both in the language as personally
i have use cases where ADTs won't work.
examples:
- `sealed class UnionType permits ArrayKeyType, NumType` (
https://github.com/azjezz/psl/tree/1.7.x/src/Psl/Type/Internal )
- `sealed interface ExceptionInterface permits Exception` (
https://github.com/azjezz/psl/blob/1.7.x/src/Psl/Type/Exception ) - applies to
all components in library
- `sealed class Exception permits AssertException, CoercionException` (
https://github.com/azjezz/psl/blob/1.7.x/src/Psl/Type/Exception )
- `sealed class ResourceHandle permits
Psl\Filesystem\Internal\ResourceFileHandle` (
https://github.com/azjezz/psl/blob/asio/src/Psl/IO/Internal /
https://github.com/azjezz/psl/tree/asio/src/Psl/Filesystem/Internal )
This is just a list of top of my head, the protection `sealed` offers is at the
same level of `final`, expect it allow me to use inheritance internally without
allowing the end users to do so.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
