Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114232 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26038 invoked from network); 28 Apr 2021 12:02:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Apr 2021 12:02:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id F1D8B1804BD for ; Wed, 28 Apr 2021 05:06:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 28 Apr 2021 05:06:33 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:1205:502d:fa80:744d:2e84:c880:cee4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id E54DE1509684 for ; Wed, 28 Apr 2021 14:06:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 28 Apr 2021 14:06:23 +0200 References: <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <179049b1475.11134368b213512.254739612773841999@void.tn> <722ed544-69e3-3be4-f828-185914617228@processus.org> <51fffd88-03c7-463d-a6d7-94c086cb5893@www.fastmail.com> To: PHP Internals In-Reply-To: Message-ID: <89342DDE-5F0A-48F2-A7A7-7660FDD70EA4@cschneid.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes From: cschneid@cschneid.com (Christian Schneider) Am 28.04.2021 um 01:00 schrieb Larry Garfield : > 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. >=20 > 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. >=20 > See also: This thread. :-) >=20 > 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 : > 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