Re: [RFC] Property hooks, nee accessors

From: 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.

« previous php.internals (#120278) next »