> On 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.
But, are we really, stuck?
You successfully introduced enumerations. Why not also data types and control
flow types?
Just asking for a "friend."
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
