Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114226 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94295 invoked from network); 28 Apr 2021 07:35:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Apr 2021 07:35:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B94C01804B5 for ; Wed, 28 Apr 2021 00:39:37 -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.1 required=5.0 tests=BAYES_05,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (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 00:39:37 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id D06B15101324; Wed, 28 Apr 2021 07:39:34 +0000 (UTC) To: Christian Schneider , PHP Internals References: <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <179049b1475.11134368b213512.254739612773841999@void.tn> <722ed544-69e3-3be4-f828-185914617228@processus.org> <439D6A05-140B-4727-B8A9-D7833D568858@cschneid.com> Message-ID: <8e1c81c8-03d7-7b72-6667-956579d8a8a3@processus.org> Date: Wed, 28 Apr 2021 09:39:34 +0200 MIME-Version: 1.0 In-Reply-To: <439D6A05-140B-4727-B8A9-D7833D568858@cschneid.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes From: pierre-php@processus.org (Pierre) Le 28/04/2021 à 00:25, Christian Schneider a écrit : > 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. Yes, I get your point. Anyway, operator overloading and multiple inheritance raise much more complex technical details, and much more specification to be written, and induce much more magic in the air ! Sealing a class doesn't induce any change in behavior, doesn't induce any functional spec, doesn't hide any runtime flow behind magic, doesn't forces to redact and implement some kind of resolution order mechanism or hidden magic, it's just a finer variant of the already existing final keyword. > 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. Any powerful tool can be misused, I mean this argument is real for all of: exceptions, switch statements, final methods, traits, basic inheritance, magic methods, bit flags, type coercion, etc, etc etc,... I think that the sealed classes, by the fact they reduce usability of classes themselves is not something that gets promoted, but rather something that will be used in edge cases where it makes sense. Of course, people will always end up, at some point, using it the wrong way, but hey, we're all doing open source, community feedback and review is the best of all ways to avoid that major libraries or software used by many will end up polluting their code with such bad code :) > 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 ;-) 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). Even in my daily work working for client proprietary projects, I always write final per default everywhere, so that we spot those changes in peer review and have the reflex to ask "why did you extend ? wasn't it possible to decorate, write an interface, or fix the bug ?". In that regard, for many cases, sealed classes may be something to us, because it could fit in our production workflow, not everywhere, (I'd reassure you, I'm not going to write "sealed" everywhere) nevertheless it has a real added value and meaning when writing business critical code path that need extra testing and stability in the long term. Regards -- Pierre