On Wed, Apr 28, 2021, at 7:06 AM, Christian Schneider wrote: > Am 28.04.2021 um 01:00 schrieb Larry Garfield <la...@garfieldtech.com>: > > 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 ... > > Am 28.04.2021 um 09:39 schrieb Pierre <pierre-...@processus.org>: > > Yeah, final is something, I originally come from the Java world 20 years > > back, and it never hit me as something terrible in PHP, on the contrary, I > > use it "per default" personally to promote composition over inheritance, > > but when I do that I mostly write interface and composition based APIs > > which much more flexibility than an open to extension design (TL;DR: I > > always give the user an escape route other than inheritance, and document > > it). > > Those are good points you are bringing up. > You're basically saying that classic OOP has outlived itself in many > cases - something I agree with - and we need the ability to use other > patterns. > > With that in mind I'm not sure if we really want to tack all this > functionality on to "class". > I think it would be better and less confusing to most developers if we > were to bite the bullet and try to do it right. > Especially since my impression is that we only need to tack it on to > "class" if there is urgency and personally I'm not feeling it. > But then again YMMV. > > You convinced me from a -1 to considering abstaining from the vote ;-)
Ha! Progress. :-P As I've indicated before, there are two possible paths to an essentially similar end goal, both of which have RFCs written but no code written: Sealed classes and the ADTs proposal. Sealed classes is built on, well, classes. ADTs are build on enums, which in PHP are themselves built on classes. In practice, some languages do one, some do the other, and I think one or two may do both. For the use cases I can envision, I think either would work. Sealed classes would be a bit more flexible, while Enum-based ADTs would be more compact and convenient in the typical case. There's one or two use cases I'd like to be able to implement where ADTs would probably not be sufficient (state machines), but then Sealed classes would be annoyingly verbose in those cases, so... I'm still mostly open to either approach, and not convinced that we need both (though I could be convinced, potentially). In practice, I think I'm good with whichever one someone is able to get implemented first, which is always the hard part of any proposal. (Someone else, I forget who, suggested type aliasing as another solution, where you'd just have multiple classes and, in effect, type alias a union of those classes to a new name and tell people to use that. I like type aliases, but I'm not convinced that's a viable solution in this case. It's very round-about.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
