On Tue, Feb 27, 2024 at 6:22 PM Bruce Weirdan <[email protected]> wrote:
>
> Hi Larry and others
>
> On Fri, Feb 23, 2024 at 12:57 AM Larry Garfield <[email protected]>
> 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:[email protected]
