> 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