Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114153
User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b
Mime-Version: 1.0
Message-ID: <fdb9d6b5-4ef1-488c-b484-94706b288a39@www.fastmail.com>
In-Reply-To: <179097c0182.121a28de2250923.6774005422437895662@void.tn>
References: 
 <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org>
 <CAJpLVh2UybGgAqhfAGQ=kKQ-qvmG68HWKaUJXOwPv7DgEbAdKw@mail.gmail.com>
 <179049b1475.11134368b213512.254739612773841999@void.tn>
 <CAJpLVh0pz_WopKza=XXqPrvS4bQZhWom1FQ6QLW-fbC-8JHkrA@mail.gmail.com>
 <CADyq6sLtgNkyM-qQcwRY8mMOxnkrz_9qeG6XK2uDBqsh=smMtg@mail.gmail.com>
 <CAJpLVh3C63FTUzWusVOp5JOGpuKbOYi0WovYvNFv20npNJFh3g@mail.gmail.com>
 <b4276d92-4856-4222-8c34-55b1422030c5@www.fastmail.com>
 <CAJpLVh0HWzdOPGLFp4sRUQYKrcbUBM+4pacL5urmWArTLB2nbw@mail.gmail.com>
 <179097c0182.121a28de2250923.6774005422437895662@void.tn>
Date: Sun, 25 Apr 2021 11:45:42 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Apr 25, 2021, at 9:43 AM, Saif Eddin Gmati wrote:
> ---- On Sun, 25 Apr 2021 08:39:37 +0100 Olle H=C3=A4rstedt=20
> <olleharstedt@gmail.com> wrote ----
>=20
>  > > In practice, I think all of the use cases for sealed classes are=20=

> ADT-esque.=20
>  > > As I noted before, combining sealed classes with Nikita's=20
> new-in-expressions=20
>  > > RFC would allow for this (also using my short-functions RFC for=20=

> this=20
>  > > example, although that's a nice-to-have):=20
>  > >=20
>  > > sealed class Maybe permits Some, None {=20
>  > >=20
>  > >   public const None =3D new None();=20
>  > >=20
>  > >   static public function Some($x) =3D> new Some($x);=20
>  > >=20
>  > >   public function value() =3D> throw new NotFoundException();=20
>  > >=20
>  > >   public function bind(callable $c) =3D> static::None;=20
>  > > }=20
>  > >=20
>  > > final class None extends Maybe {}=20
>  > >=20
>  > > final class Some extends Maybe {=20
>  > >   private $val;=20
>  > >   private function __construct($x) { $this->val =3D $x; }=20
>  > >=20
>  > >   public function value() =3D> $this->val;=20
>  > >=20
>  > >   public function bind(callable $c) =3D> new static($c($this->val=
));=20
>  > > }=20
>  > =20
>  > Yes, the Maybe/Option type is a good example! Because you know ther=
e=20
>  > will never be another extension. But it's worth noting that wheneve=
r=20
>  > you do *not* know that, these concepts suffer, even in functional=20=

>  > programming, by the same issues as I mentioned before with regard t=
o=20
>  > maintainability - you can't easily extend it without touching old=20=

> code=20
>  > (there are attempts to fix this by making algebraic datatypes=20
>  > extensible, but it didn't get widely adopted AFAIK). Also see this=20=

>  > thread about the expression problem:=20
>  > https://stackoverflow.com/a/871375/2138090=20
>  > =20
>  > Disregarding the limitations of maintainability, the real power of=20=

>  > algebraic datatypes is of course the pattern matching functionality=
=20
>  > seen in OCaml and Haskell. I'm leaning towards tagged unions +=20
> pattern=20
>  > matching have more to offer PHP than sealed classes (and even more=20=

> so=20
>  > when pattern matching can be extended with guard clauses and=20
> catching=20
>  > exceptions). The RFC author(s) might want to extend the RFC to=20
> reflect=20
>  > the relation to tagged unions, and how they overlap (or not)?=20
>  > =20
>  > Olle=20

Pattern matching as it's currently being worked on would apply to arbitr=
ary objects with visible properties, and enums are, in the engine, "just=
 objects."  So both a sealed class with public properties (or rather, pr=
operties visible in the scope) and an Enum with properties added (tagged=
 unions/ADTs) would look the same to pattern matching.  Naturally that R=
FC 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 (=20
> https://news-web.php.net/php.internals/114134 ), there's many=20
> differences between ADTs and Sealed classes,
> and in my opinion that's enough to have them both in the language as=20=

> personally i have use cases where ADTs won't work.

Many differences in terms of their implementation details, yes.  Ilija l=
ays out a good list of those in that email.  However, they do address th=
e same conceptual problem space.

Is there anything that ADTs or sealed classes would enable that the othe=
r 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 comparis=
ons 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 ext=
ension 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 alread=
y offers), it would be no new keywords.  Minimizing new keywords is gene=
rally a good idea anyway.