Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119063 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38643 invoked from network); 30 Nov 2022 15:47:06 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Nov 2022 15:47:06 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D341D180339 for ; Wed, 30 Nov 2022 07:47:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 30 Nov 2022 07:47:05 -0800 (PST) Received: by mail-vs1-f52.google.com with SMTP id k17so9819209vsr.10 for ; Wed, 30 Nov 2022 07:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ClSA7o8cVAqujS9uBn6HjBhg6bzkW/mtF+RRvchPbv8=; b=nUSr+ijiS5SMtQF1sjpbeqDupSz69zt3t9ke6fen0ZtzldA3NiSV8MB6rD+lvtE4au fqyuPlusUmiMlIERzo5DMIgGOtjIfRHJHhJlklrUx5Rff+wFX+iMAPaiqhKnCElE/7xQ iEUhGkOmp8VkSqPKOS/1xSAqYr8qTNwMJJj4O11mVIw43/32HHQ0QFIUZZu/Ol/eiyN1 Cudq0jAMYVu9DCerQIw5Bh7PxJe9GAlzI3C887L4IBwIxSoIRytWZ7IoeKeGwqjHO11Y Ra38NR2tIFkhjZ6ghv9ml1TdV3xIGlqrL+Bn/KtgEmVVIfrE6Jj2AG1VeBgs5TPqzwjh Uc4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ClSA7o8cVAqujS9uBn6HjBhg6bzkW/mtF+RRvchPbv8=; b=0nvcEczSFimIBWqrao2DEf1G6XslMItfmKmdj9mCWN+1E+K3K4u5fGqJif+OwuPqAh Pze5RTfTwZHO3exYI8MUglfnubnad52OnzW7OFG7RaC8A2Xvhiig0ZYyWwCT1fKcyxyn jLaOk0pNxQ3b3hsiIzrQHJmWiIkkLJZhhzkHosYmIl8CX7cbrAxtrhj1GrmXWGyAF9/1 2At6s7dWS2VCC/ZgqNfPXXWuHBF6D4pdJwcXSQ1JCrXuTOut1incd0LQKIJPRtSvwASx G76Vyr6p88ENDSAjPLgNvOCmOp18tz//0fOzPsaXWKQNXXmoymvSKfIgpljgNJMfCoEp TeGA== X-Gm-Message-State: ANoB5pnBZ95OZ0lAKkpKxiNQOatjo+1sp9Am4rEFAmswxOWTMXos/PbS kqBXjCC1/GFGuK7clT4TiQgYhfGEyhMACgXLQCB8Lo/e X-Google-Smtp-Source: AA0mqf6VgQi3xlTCeuk6I3b5RVXRWcHM95lmbwrGXbzOqpvYbJNC8kJogER5nxI32/IRR1xnBJvtOYQYT7mdSU94mm8= X-Received: by 2002:a05:6102:c8e:b0:3b0:c848:e379 with SMTP id f14-20020a0561020c8e00b003b0c848e379mr3640502vst.55.1669823224752; Wed, 30 Nov 2022 07:47:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 30 Nov 2022 12:46:28 -0300 Message-ID: To: "G. P. B." Cc: Marco Pivetta , =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , PHP Internals List Content-Type: multipart/alternative; boundary="00000000000026328005eeb204a7" Subject: Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments From: deleugyn@gmail.com (Deleu) --00000000000026328005eeb204a7 Content-Type: text/plain; charset="UTF-8" After reading GPB, Nicolas, Jordan and Larry's considerations, I no longer have any objections to this RFC. Here is my summary of it all: - It's very easy for everyone to wrongly interpret readonly as somewhat immutable, but it isn't (docs/education issue) - LSP is about the writer of the child class, not about PHP - If you don't want child classes to violate LSP, make your class `final readonly` - readonly as "constructor-init" properties mindset make it even stronger the argument that child classes should be free to choose their definition because constructors are special methods not bound by inheritance. Overall the most important aspect for me was that there was a pragmatic decision of supporting readonly properties as it covers most of the need without the whole hustle/complexity of asymmetric visibility and it was very good for Nicolas to bring up again that pragmatic notion. This doesn't have to be complex and limiting child classes makes it more complex. In the future, the education around readonly keyword will be that it has no bearings anywhere except the class that makes use of the keyword. -- Marco Deleu --00000000000026328005eeb204a7--