Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114146 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 7987 invoked from network); 25 Apr 2021 14:39:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Apr 2021 14:39:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6D6E31804DB for ; Sun, 25 Apr 2021 07:43:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from sender4-of-o56.zoho.com (sender4-of-o56.zoho.com [136.143.188.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 25 Apr 2021 07:43:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619361793; cv=none; d=zohomail.com; s=zohoarc; b=NJ0ov5iW9p5ElkjWJBmoo5nb3YyF2xv8Bbgmm81qcEnVHtqM+7zf6AxEH6oozMhU16VCkc1bVEkRt1p+9BHl3XwCLKL83MXDogVhrU/jhsT/LoasDG9R/Fy8uu36hwHeikAhKCcGkXh/R/wXRZqvicq7LsbP9jLIFEYW0wqTRms= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619361793; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=s6c+sHm4Sa5ZcNrFOIUXELx/Yfuvm43IZRDpXjHeMp8=; b=WlJiQ9T2hnwtDHX5bw8+o22E+WhA5cTNOOr5x0mb02y3aMXrWTKR8jMhmVtztQOSnmws+ZpSSNtQbDEXj2yyqFXVOx3TjaBtx3W1aOX4iS3Uu6BE9kEpJsFOWy6kwArm7E3ipH/jyRkQLHBfPS70RRDIvpLFxLxwqB6BPCxozEY= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=azjezz@void.tn; dmarc=pass header.from= header.from= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1619361792407727.8191657404184; Sun, 25 Apr 2021 07:43:12 -0700 (PDT) Date: Sun, 25 Apr 2021 15:43:12 +0100 To: =?UTF-8?Q?=22Olle_H=C3=A4rstedt=22?= Cc: "Larry Garfield" , "php internals" Message-ID: <179097c0182.121a28de2250923.6774005422437895662@void.tn> In-Reply-To: References: <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <179049b1475.11134368b213512.254739612773841999@void.tn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes From: azjezz@void.tn (Saif Eddin Gmati) ---- On Sun, 25 Apr 2021 08:39:37 +0100 Olle H=C3=A4rstedt wrote ---- > > In practice, I think all of the use cases for sealed classes are ADT-e= sque.=20 > > As I noted before, combining sealed classes with Nikita's new-in-expre= ssions=20 > > RFC would allow for this (also using my short-functions RFC for 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 there=20 > will never be another extension. But it's worth noting that whenever=20 > you do *not* know that, these concepts suffer, even in functional=20 > programming, by the same issues as I mentioned before with regard to=20 > maintainability - you can't easily extend it without touching old 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 + pattern= =20 > matching have more to offer PHP than sealed classes (and even more so=20 > when pattern matching can be extended with guard clauses and catching=20 > exceptions). The RFC author(s) might want to extend the RFC to reflect= =20 > the relation to tagged unions, and how they overlap (or not)?=20 > =20 > Olle=20 > =20 > --=20 > PHP Internals - PHP Runtime Development Mailing List=20 > To unsubscribe, visit: https://www.php.net/unsub.php=20 > =20 >=20 As mentioned in a previous email ( https://news-web.php.net/php.internals/1= 14134 ), there's many differences between ADTs and Sealed classes, and in my opinion that's enough to have them both in the language as person= ally i have use cases where ADTs won't work. examples: - `sealed class UnionType permits ArrayKeyType, NumType` ( https://github.c= om/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 compone= nts in library - `sealed class Exception permits AssertException, CoercionException` ( htt= ps://github.com/azjezz/psl/blob/1.7.x/src/Psl/Type/Exception ) - `sealed class ResourceHandle permits Psl\Filesystem\Internal\ResourceFile= Handle` ( https://github.com/azjezz/psl/blob/asio/src/Psl/IO/Internal / htt= ps://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 internall= y without allowing the end users to do so.