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 ;-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
