Re: [RFC[ Property accessor hooks, take 2
| From: | Bruce Weirdan | 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