Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114271 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82225 invoked from network); 4 May 2021 14:33:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 May 2021 14:33:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 018C51804DB for ; Tue, 4 May 2021 07:39:50 -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=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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, 4 May 2021 07:39:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F07705C017C for ; Tue, 4 May 2021 10:39:48 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute4.internal (MEProxy); Tue, 04 May 2021 10:39:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L9hxVb RgUc+989WTUn4jFwkxnsHfFDW908VxszaCZLw=; b=SrxEqZIk5O++hC2VEJ5VFx t67OVuyfNR4EPe8RukIo/EULAcTA2ZmXIGwA36Dcvh6X+pWE5ZPO29h+lIu+TixM 9VVwb3KXnMrKzUF3dK6XqPTHU3aU60YlNCTiHhzJ06QpdEf//Fl94RESDNXV30pN nsSm7GKGafSnFYI/blaUiZLa9HHLQLTTfjYwe1FrvS5tEVL91y72cDH56usL6nkQ JFmchgAcRXCGy7iNby86I+39Eyb6ZDKgJJv1UwqZfZ8ztLB5yB31kyn0PkB8IYH3 FSlarxZtn32Z2i5EC6ryiA8qgBJbQZqZNCorX660s8jkLuJmF4LqA6lZzY0JkuwQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefiedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeevheehvdevjeelvdevgfelvefftdejkeelvdekgeeh fffgiedvjefhhfeltdduteenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhi vghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6B2A33A03C1; Tue, 4 May 2021 10:39:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-442-g5daca166b9-fm-20210428.001-g5daca166 Mime-Version: 1.0 Message-ID: <93aeeb05-64fd-4dda-8115-553c9fd29c45@www.fastmail.com> In-Reply-To: References: Date: Tue, 04 May 2021 09:39:28 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] Property accessors From: larry@garfieldtech.com ("Larry Garfield") On Tue, May 4, 2021, at 5:33 AM, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and properties with asymmetric > visibility (public read, private write) as a side-effect. > > The proposal is modeled after C#-style accessors (also used by Swift), and > syntactically similar to the previous > https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 proposal. > > While I put a lot of effort into both the proposal and the implementation, > I've grown increasingly uncertain that this is the right direction for us > to take. The proposal turned out to be significantly more complex than I > originally anticipated (despite reducing the scope to only "get" and "set" > accessors), and I'm sure there are some interactions I still haven't > accounted for. I'm not convinced the value justifies the complexity. > > So, while I'm putting this up for discussion, it may be that I will not > pursue landing it. I think a lot of the practical value of this accessors > proposal would be captured by support for read-only (and/or private-write) > properties. This has been discussed (and declined) in the past, but > probably should be revisited. > > Regards, > Nikita This is an amazingly detailed RFC, and I love most of it. Thank you, Nikita! Regarding complexity, can you elaborate on what the most complex/tricky/problematic parts are? I'm mainly wondering if there are any parts that could be changed/slightly scaled back that would reduce the complexity more than it reduces capability. (Eg, removing guard and lazy for now is a good call, IMO, since both can be emulated with the other two.) All else equal, though, I would favor including all of it. I would say that the visibility controls get us 70% of the benefit, not 80/90%, but I do agree that those are hugely beneficial in and of themselves. *IF* you decide to scale it back, I would strongly recommend simply dropping the explicit accessors support and leaving the rest of the syntax the same. That way we know it's forward-compatible should we decide in the future to re-introduce explicit accessors. Some other questions: 1. Do setters have arbitrary access to the object? Can they read/set arbitrary other values? I'm thinking of something like this: class Person { private string $firstName; private string $lastName; private string $nickname; private int $age; public string $fullName { get { return "$this->firstName $this->lastName"; } set($fullName) { if ($this->age > 50) throw new Exception('You are too old to change your name.'); [$this->firstName, $this->lastName] = explode(' ', $fullName); $this->nickname = substr(0, 5, $this->firstName); } } } (A contrived example, obviously.) 2. My knee-jerk thought is to agree with Marco and avoid references entirely, for the sake of everyone's sanity. However, it is implied that &get is the only way to properly handle array property accessors. Am I understanding that correctly? If not, can you expand on array handling? I'd happily jettison references if arrays can still be supported nicely without them. 3. The partial incompatibility with constructor promotion is understandable, but disappointing. Is it at all possible to modify the promotion logic such that if a property is already defined with accessors, you can still promote it without a syntax error? I am thinking of this case: class Test { private int _$foo; public int $foo { get { return $this->_foo; } set ($foo) { if ($foo < 0) throw new InvalidArgumentException('Must be positive.'); $this->_foo = $foo; } } public function __construct(public int $foo) {} } (Though a guard would be nicer, as it avoids the second variable, but there are other considerations there.) 4. I still don't love $value being a magic name in setters. Being able to specify it explicitly is nice, and I would probably always use that myself (and push for it in coding standards), but would it be feasible to default it instead to the name of the variable? Since that variable name cannot be a backing variable, we know that it won't conflict with anything, but it would be more self-documenting. Thanks again, and I do hope you can be convinced all this effort is worth bringing to a vote. :-) --Larry Garfield