On Sun, Apr 25, 2021, at 9:43 AM, Saif Eddin Gmati wrote:
> ---- On Sun, 25 Apr 2021 08:39:37 +0100 Olle Härstedt
> <olleharst...@gmail.com> 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
Pattern matching as it's currently being worked on would apply to arbitrary
objects with visible properties, and enums are, in the engine, "just objects."
So both a sealed class with public properties (or rather, properties visible in
the scope) and an Enum with properties added (tagged unions/ADTs) would look
the same to pattern matching. Naturally that RFC has to get finished first,
but assuming it is, it would apply either way.
(Discrete but complementary components FTW.)
> 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.
Many differences in terms of their implementation details, yes. Ilija lays out
a good list of those in that email. However, they do address the same
conceptual problem space.
Is there anything that ADTs or sealed classes would enable that the other one
simply couldn't? If we can get a list of those, that can help us determine
which is the ideal route to pursue or if there really is value in adding both
despite their heavy overlap.
(The list of links you had before lacks enough context for me to figure out
what you're suggesting, sorry. Please provide more precise comparisons of the
two here.)
----------
Also, another syntax suggestion:
final class Foo permits Bar, Baz {}
class Bar extends Foo {}
`final` already indicates that a class is inextensible. Sealed classes are
poking holes in that guard. Essentially, final on its own is an extension
cardinality of 0, sealed classes offer an exception list to that to give a
precise cardinality list.
The main advantage here is that it introduces only a single new keyword, not
multiple. If `permits` were replaced with `for` (as the RFC already offers),
it would be no new keywords. Minimizing new keywords is generally a good idea
anyway.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
