Okay, I promise I'll make this my last word on the thread, for the sake of
my own sanity and at this point, I'm sure that of others - first, I really
appreciate your explanation there for why you consider this RFC a good
thing, so thank you for that. Personally, my objections still stand for in
essence the same reasons as before;
1. In respect of data modelling, you may think you've understood a model
such that its sum is closed, this may even be true for your use case (and
yes, agree both that this is useful and some other languages have better
ways of expressing it) but sometimes, it is only true until it isn't. E.g.
you have said colours are red, green and blue. This is fine until someone
else needs to reason about purple and can't because your data model says
there is no purple.
2. A (non-functional) attribute [or other syntax/convention] for sealed
does not / should not be interpreted as saying "pretty please, don't extend
me", it says "I don't endorse/support this, but if I haven't accounted for
your use case and you're confident you understand your problem, hey, don't
let me stand in your way" - other interpreted languages (Python comes to
mind) use this approach very effectively and their ecosystems are not
automatically riddled with bad models as a result. Indeed PHP is in some
respects unusually strict for an interpreted language (though I am not
saying that is necessarily a bad thing).
3. That there are valid use cases for a language construct does not mean
people will only use it for those cases - I'd go as far as to say they
definitely won't. Annotation in some form is safe in all use cases, fatal
errors aren't. So I stand by the real, primary benefit of these constructs
- delineation of intent boundaries - is achieved without creating a
construct which introduces a new fatal error condition.
Anyway, yeah - I've said my piece(s) and I'm not a voting member so what I
think doesn't matter to that end. I hope my input on internals discussions
is not entirely moot, though; just like everyone else I take part because
I'm very fond of PHP and have an interest in its future. Appreciate those
who are willing to hear me out.
On Wed, Apr 28, 2021 at 12:00 AM 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.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
