Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113060 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 27483 invoked from network); 3 Feb 2021 15:10:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Feb 2021 15:10:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C0D2E1804E2 for ; Wed, 3 Feb 2021 06:54:14 -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=0.4 required=5.0 tests=BAYES_20,HTML_MESSAGE, 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, 3 Feb 2021 06:54:13 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id D12D65101324 for ; Wed, 3 Feb 2021 14:54:11 +0000 (UTC) To: internals@lists.php.net References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com> Message-ID: <3fad3054-0441-837b-d339-a094baaeb8f7@processus.org> Date: Wed, 3 Feb 2021 15:54:11 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ECB6DD29E8128B1FCBC2BDE7" 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] Analysis of property visibility, immutability, and cloning proposals From: pierre-php@processus.org ("Pierre R.") --------------ECB6DD29E8128B1FCBC2BDE7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 03/02/2021 à 15:14, Nikita Popov a écrit : > > I've written up an initial draft for property accessors at > https://wiki.php.net/rfc/property_accessors, but once again I get the > distinct impression that this is adding a lot of language complexity, that > is possibly not justified (and it will be more complex once inheritance is > fully considered). > > Overall, I'm still completely unsure what we should be doing :) > > Regards, > Nikita Hello, I love pretty much everything of this draft, it will allow to write value types in a very concise manner. Various notes thought: * Visibility modifier (public, protected, private) is useless and could be dropped entirely (I don't like var, but if that's necessary to keep it OK) for properties with asymmetric visibility directives, I don't know if the current parser will let you do that easily, but that would be a huge win for developers (even more concise code). * I love the fact that it can be combined with constructor promotion. * I love the guard and lazy features as proposed. Regarding inheritance, obviously the most important point is that interface or class contracts should not be changed, so you may open for reading a closed property, but you may not close a readable property for example. This is true for writing as well of course. You're saying basically that a get'ed property would be passed by-value and thus it would forbid indirect access such as adding values to an array ? But what if the compiler could detect that get; is just get and not a function behind and compile opcodes as if it was a normal property (I don't know Zend internals at all, just guessing here) and considers that any other more complex getter to just be incompatible ? I guess that in languages such as C# that implement such asymmetric visibility mechanism, they always return object references, so this kind of problem just doesn't exist. Thank you so much for this draft, I love the path it follows. Regards, -- Pierre --------------ECB6DD29E8128B1FCBC2BDE7--