Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114219
User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b
Mime-Version: 1.0
Message-ID: <c6f64453-557e-4172-a688-36dcacd7a065@www.fastmail.com>
In-Reply-To: 
 <CA+p1FaauZvsraPLS86EhnipxoN_9xJXRit2DEaFCxiBJc9Pi2w@mail.gmail.com>
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>
 <EA268E52-2954-40DE-B3CC-D447A4983887@cschneid.com>
 <CAC5V6gghaZv=MCQz+FWNDAMUj2KorjvL_tNO+DNAPT0ioycpSA@mail.gmail.com>
 <CA+p1FabuUDUzMkEhwyy0BJVd71N=6ubn5pEJNh8VkE8D9rJhow@mail.gmail.com>
 <722ed544-69e3-3be4-f828-185914617228@processus.org>
 <CA+p1FaZjWc+cMrfWkGP5LCmv6YOKF3h7dY_yYXxCmfUpRfp4fw@mail.gmail.com>
 <CAAKU0u=MrTOCME-omM0Vh_j2Wwu89V6+gWp8eJj19MweJ00vHw@mail.gmail.com>
 <CAPKYkKyRWmpByUrtjJ7U67gdj8a7eM0kE-qxKPnLLEsVFQkZ3w@mail.gmail.com>
 <CAJpLVh37Lq44sDSKDCqBk1HKtML1dyu0v4+V8LBSr8Hnu67KoQ@mail.gmail.com>
 <CAPKYkKx77Q0WFvJdQ7ag9wvLNYM5r9xkrPRWER1pHBr8KH_08Q@mail.gmail.com>
 <51fffd88-03c7-463d-a6d7-94c086cb5893@www.fastmail.com>
 <CA+p1FaauZvsraPLS86EhnipxoN_9xJXRit2DEaFCxiBJc9Pi2w@mail.gmail.com>
Date: Tue, 27 Apr 2021 18:00:22 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote:
> On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> 
> The two options to prevent such errors are:
> >
> > 1. Sealed classes.
> > 2. Extend Enums into ADTs.
> >
> 
> Unless I've misunderstood your example, there is a third option which quite
> possibly prevents the error in a nicer, easier to reason about, more
> flexible pattern.
> 
> class Perhaps extends Maybe implements OperatesOnTheValueInterface { ... }

If we were dealing with a service object in classic OOP (viz, OOP based on classes), then yes, turning the function into a method and using polymorphism would be the correct answer, rather than RTTI.

However!  Classic OOP design patterns are not all that PHP supports, and that's a good thing.  The "class" construct, for better or worse, is the syntax for logic objects, value objects, data objects, and control flow objects (such as Maybe, Either, etc.), plus assorted other patterns that are not part of the classic OOP canon.  But they're still good and useful patterns, and often a better model than classic OOP "polymorph all the things" approaches.

If we were designing PHP from scratch today, I'd argue for having separate language constructs for funcy-syntax-closures (which is what service objects are), product types (structs, value objects, all the same thing), and control flow types.  Many newer languages do differentiate those better.  That's not where we are, though, so we're stuck with class being the uber-syntax for anything even slightly interesting from a type perspective.  So be it, but it does lead to ample confusion about which use case you're talking about, especially when not everyone is familiar with all of the different, distinct use cases.

See also: This thread. :-)

Sealed classes are... not really useful at all for service object use cases.  They are useful for product type and control flow type use cases.

--Larry Garfield