Hi Larry and others
On Fri, Feb 23, 2024 at 12:57 AM Larry Garfield <la...@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
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
