On Tue, Apr 27, 2021 at 7:00 PM Larry Garfield <la...@garfieldtech.com>
wrote:
> On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote:
> > On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield <la...@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.
>
>
And I think that is where our approaches differ. You feel that since sealed
classes are useful for at least one of the ways classes can be used in PHP,
then we should make them available even if that means they end up getting
used with the ways that they don't make sense. My feeling is that we
shouldn't introduce something that would cause restrictions where they
don't make sense just so we can have them where they do.
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
