Re: [RFC] Property hooks, nee accessors
| From: | Hendra Gunawan | Date: | Mon, 15 May 2023 05:58:23 +0000 |
| Subject: | Re: [RFC] Property hooks, nee accessors | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120278@lists.php.net to get a copy of this message | ||
On Tue, May 9, 2023 at 4:38 AM Larry Garfield <larry@garfieldtech.com> wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.. It's been a
> while in coming, and we've evolved the design quite a bit just in the last week so if you saw
> an earlier draft of it in the past few months, I would encourage you to read it over again to make
> sure we're all on the same page. I'm actually pretty happy with where it ended up, even
> if it's not the original design. This approach eliminates several hard-to-implement edge cases
> while still providing a lot of functionality in one package.
>
> https://wiki.php.net/rfc/property-hooks
>
> --
> Larry Garfield
> larry@garfieldtech.com
Hi, Larry
```
interface IFace
{
public string $readable { get; }
public string $writeable { set; }
public string $both { get; set; }
}
```
How important is ``
{ get; }`` statement (and friends) in the interface?
Since PHP does not enforce method definition existence in caller site,
this code is valid (at least at compile time):
```
interface IA {
// ...
}
interface IB {
public function doIt(IA $par1);
}
class CA1 implements IA {
// makeIt is not part of IA
public function makeIt() {
echo " makeIt() is called";
}
}
class CA2 implements IA {}
class CB implements IB {
public function doit(IA $par1) {
// makeIt is not enforced to be invalid
$par1->makeit();
}
}
$a1 = new CA1;
$a2 = new CA2;
$b = new CB;
$b->doIt($a1); // valid
$b->doIt($a2); // invalid at runtime
```
IMO, ``{ get; }`` (and friends) only useful if there are:
* definition existence enforcement or implemented asymmetric visibility
* AND no default hook implementation provided.
I assume that ``{ get; }`` do exist in the property accessors
proposal because there is no default hook implementation. Whether
there is already implemented property definition existence enforcement
or not, i don't know. If yes, then all things are in the right place.
If not, it feels like a half baked feature, just like the method was:
the error will pop up at runtime. The only positive value is ```{ get;
}``` can still be consumed by static analysis tools.
```
class CX {
public function consumeIt(IFace $par) {
// this statement should trigger error
// produced by engine or SA tools
$par->readable = "hello";
}
}
```
Things will be different with property hooks. Without definition
existence enforcement nor implemented asymmetric visibility, static
analysis tools will give misconception about unlisted hooks if there
is error/warning message.
```
class CX {
public function consumeIt(IFace $par) {
// default hook is provided by engine
// any message is not relevant for this valid statement
$par->readable = "hello";
}
}
```
If there is no forward compatibility consideration, can we simplify
interface definition to this one?
```
interface IFace
{
public string $readable;
public string $writeable;
public string $both;
}
```
Thanks in advance.