Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114212 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18946 invoked from network); 27 Apr 2021 18:53:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Apr 2021 18:53:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1964D1804DD for ; Tue, 27 Apr 2021 11:57:47 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FREEMAIL_REPLY, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (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 11:57:46 -0700 (PDT) Received: by mail-lj1-f177.google.com with SMTP id a36so58574124ljq.8 for ; Tue, 27 Apr 2021 11:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=puTMBHPWVVTwc1NL1saUluXLJPxAYQU15Scm8KXHcUU=; b=glV5eTdTMysSez5t0RP2NaQCC/bAEewLHqBHaAtEJYBtr5NuWuqkFluXmZ4I8Loloy YvcnU1Z52SbXj4j7D9yOgyUJaYYHbwPhRL7nwL/uLk9K4qkkIKtm3H6HXvwEEzka2j3O 8IAtnsRszdZkhiYfA8kbrjVljhAN6fFD60pjhYGkus/wSWL1lhX/RSqp6K74+R5TRSDm n4KhKC71XwJVXqDuYqzPs+Ioqopz9RFeJczIGmU3aH3KQKB0dYZipy9z7fKeaZ13aQWa fCeg2xxLMv8Yk3R1VMqBLtWftFtqm5Xemx8a8TWzgRY3x2OEMBJ/1x51IKXFodX3QmVd +27A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=puTMBHPWVVTwc1NL1saUluXLJPxAYQU15Scm8KXHcUU=; b=AIrlc687SNDBw1fOEYIIPUKIRlnMJnj8cBJEIiQ3wStHk34WKoBB3QR4CdGHUacKXp fN7vTT5xmulYpsBHlIqOo3NMQB8wpWw5h2ZeLDu2LtCBTxrr2iJG6GrCujKqrZUmo6tv 4QKMXadEbYNF2MX5cePPYqst5j/HA7Dtg1yA1qT6tjaka7vgpk2Ho946IzR0QzZ38ciO sMDCinYzuwJj5kphplL0C/bDRYYoRZYW8ZTXUlvj2MeW0CRCQS86OhH/1f+ojLhdGZQl 7EM+H8iNW0lXTmQg8O2MpsuLmH5pexYzR8q4fDkBpbw2zhOTYkNwmp1jRUhDrXc/i17R NNXg== X-Gm-Message-State: AOAM533A/1nnjr7SFEpw8zMZLAxxVlTqe0M1yQ/oPRRXBasRRoeKqa80 t61uDlb93tFQ+hU41EOt5hG08z7nYyNHClJvqQ4= X-Google-Smtp-Source: ABdhPJyuB22db86Dyv7/U9wc9YpfbZxnlH53WBqp/uRipiNaqn/As1NNxv+5BMyuaSkAkbYQiA5ISdQlQqlRxQqC0AU= X-Received: by 2002:a2e:9ace:: with SMTP id p14mr3693026ljj.470.1619549863685; Tue, 27 Apr 2021 11:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4e13:0:0:0:0:0 with HTTP; Tue, 27 Apr 2021 11:57:42 -0700 (PDT) In-Reply-To: References: <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <179049b1475.11134368b213512.254739612773841999@void.tn> <722ed544-69e3-3be4-f828-185914617228@processus.org> Date: Tue, 27 Apr 2021 20:57:42 +0200 Message-ID: To: Chase Peeler Cc: Levi Morrison , David Gebler , Pierre , Guilliam Xavier , Christian Schneider , PHP Internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=) 2021-04-27 20:17 GMT+02:00, Chase Peeler : > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals < > internals@lists.php.net> wrote: > >> I think the conversation on final classes being "bad" has gone on long >> enough. You don't like final, and you don't want to see more features >> like it being added, such as sealed. Point taken. Now please stop >> dominating the discussion, thank you. >> >> > I think the legitimacy of final/sealed classes goes to the heart of this > RFC. As long as people are going to discuss it and bring up counter points, > then I think asking someone to stop defending their view is a bit out of > line. > > That being said, David has never said he is against developers being able > to annotate their classes as being final or sealed. He is just against the > engine enforcing such requirements. On this I agree. I understand that > other languages support this concept - and frankly, I don't care. The > flexibility that PHP offers has always been one of its greatest strengths > and this just further erodes that. > > >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >> > > -- > Chase Peeler > chasepeeler@gmail.com > Sometimes it's helpful to apply a risk perspective the shed some light under hidden assumptions of different arguments. For example, what's the probability and impact of an event that would limit a coder when a library is using a sealed class? And the other way around, what's the probability and impact of an event that would decrease code quality when a sealed class is *not* used (like being able to subclass Maybe/Option even when it "shouldn't" be possible)? If the probability of such an event is high, but the impact to overall code quality is low, the risk is also considered low. (Example: Just create your own Maybe class. Of course harder with more elaborate classes, you don't want to copy-paste an entire library. And the other way, extending Maybe is a very local thing to do and doesn't hurt the library itself.) When both probability and impact are uncertain, it will make it harder to create consensus, and will make arguments more emotional or heuristic. When risk is low and the benefit high (and clear), consensus is easy. Olle