Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114217 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47147 invoked from network); 27 Apr 2021 22:20:55 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Apr 2021 22:20:55 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 179921804DC for ; Tue, 27 Apr 2021 15:25:18 -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=-0.5 required=5.0 tests=BAYES_05,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 ; Tue, 27 Apr 2021 15:25:17 -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 732E3150D068 for ; Wed, 28 Apr 2021 00:25:15 +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 00:25:14 +0200 References: <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <179049b1475.11134368b213512.254739612773841999@void.tn> <722ed544-69e3-3be4-f828-185914617228@processus.org> To: PHP Internals In-Reply-To: <722ed544-69e3-3be4-f828-185914617228@processus.org> Message-ID: <439D6A05-140B-4727-B8A9-D7833D568858@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 27.04.2021 um 19:19 schrieb Pierre : > I think that the debate "but if your seal your classes I won't be to = extend it" is overrated: it's not the language to chose whether or not = the library/software author can seal its classes or not, it's up the = library/software author to do its own choice. And in that regard, having = "sealed" classes in the language is actually bringing that possibility = to the library author, so it's more liberty. The same - "it is more liberty" - could be said about operator = overloading, multiple inheritance and many other language features which = lead to people using them in ways / places I consider harmful. So I'd = rather not have them in my language of choice. I'm not saying the feature is completely useless in the right hands but = I think it will be misunderstood and promotes bad habits. Think people = abusing exceptions for flow control. But then again maybe I'm just traumatized by people putting final all = over the place in Java back in the days. I'm sure people in 2021 know = better than that /s ;-) - Chris