Re: [RFC[ Property accessor hooks, take 2

From: Date: Mon, 11 Mar 2024 16:13:37 +0000
Subject: Re: [RFC[ Property accessor hooks, take 2
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-122612@lists.php.net to get a copy of this message
On Tue, Feb 27, 2024 at 6:22 PM Bruce Weirdan <weirdan@gmail.com> wrote: > > Hi Larry and others > > On Fri, Feb 23, 2024 at 12:57 AM Larry Garfield <larry@garfieldtech.com> wrote: > > > > > > I've added an FAQ section explaining why the Python/JS approach wouldn't really > > work. To be clear, Ilija and I spent 100+ hours doing research and design before we started > > implementation (back in mid-late 2022). We did seriously consider the JS-style syntax, but in the > > end we found it created more problems than it solves. For the type of language PHP is (explicit > > typed properties), doing it on the property itself is a much cleaner approach.. > > > The section you added [1] seems to focus on having both `public string > $fistName and public function get/set firstName():string`, and > how > it's hard to keep types and visibility in sync. But I'm not sure if > you considered making properties and accessors mutually exclusive. I > mean the following: > > ```php > class Person > { > public string $firstName; // compile time error, setter/getter defined > > public function __construct(private string $first, private string $last) {} > > public function get firstName(): string // compile time > error, property defined > { > return $this->first . " " . $this->last; > } > > public function set firstName(string $value): void // compile > time error, property defined > { > [$this->first, $this->last] = explode(' ', $value); > } > } > ``` > > This seems to address most of the counterpoints you listed, to some degree: > > > What is the property type of the $firstName property? > > Well, you propose to allow wider write-types yourself, so the question > would apply there as well. But presumably, the property type is its > read type - so whatever getter returns. > > > but there's nothing inherent that forces, public string $firstName, get firstName()s > > return and set firstName()s parameter to be the same. Even if we could detect it as a compile error, > > it means one more thing that the developer has to keep track of and get right, in three different > > places. > > With mutually exclusive accessors and properties it becomes just two > places. And yes, accessor consistency would need to be checked at > compile time. But the same can be said for the widening of write type > you proposed. > > > What about visibility? Do the get/set methods need to have the same visibility as the > > property? > > When there's no property the question becomes moot. > > > If not, does that become a way to do asymmetric visibility? > > Yes. > > > What about inconsistency between the method's visibility and the property visibility? > > How is that handled? > > There's no inconsistency when there's no property. Accessor visibility > can be different - allowing the asymmetric visibility you wanted to > implement in your other RFC. > > > How do you differentiate between virtual and non-virtual properties? > > This one is hard to answer without asking another question: why would > you need to? Does the requirement to know it stem from engine > implementation details, or do you need as a person writing code in > PHP? > > > For non-virtual properties, if you need to triple-enter everything, we're back to > > constructors pre-promotion. Plus, the accessor methods could be anywhere in the class, potentially > > hundreds of lines away. That means just looking at the property declaration doesn't tell you > > what its logic is; the logic may be on line 960, which only makes keeping its type/visibility in > > sync with the property harder. > > Forbidding property declaration reduces that to double. The rest is > mostly stylistic and can be said about traditional > (non-constructor-promoted) properties as well. > > Now this approach naturally has some open questions, foremost about > inheritance. But we probably don't need to go into those details if > you already explored this way and found some technical obstacles. If > you did, it would probably make sense to list them in the FAQ section. > > [1] > https://wiki.php.net/rfc/property-hooks#why_not_pythonjavascript-style_accessor_methods Resending this since I've never got a reply and it's quite possible the message got lost due to mail list issues. -- Best regards, Bruce Weirdan mailto:weirdan@gmail.com

« previous php.internals (#122612) next »