On Thu, Feb 22, 2024 at 1:03 AM Pierre <[email protected]> wrote:
>
> Le 21/02/2024 à 19:55, Larry Garfield a écrit :
> > Hello again, fine Internalians.
> >
> > After much on-again/off-again work, Ilija and I are back with a more
> > polished property access hooks/interface properties RFC. It’s 99%
> > unchanged from last summer; the PR is now essentially complete and more
> > robust, and we were able to squish the last remaining edge cases.
> >
> > Baring any major changes, we plan to bring this to a vote in mid-March.
> >
> > https://wiki.php.net/rfc/property-hooks
> >
> > It’s long, but that’s because we’re handling every edge case we could think
> > of. Properties involve dealing with both references and inheritance, both
> > of which have complex implications. We believe we’ve identified the most
> > logical handling for all cases, though.
> >
> > Note the FAQ question at the end, which explains some design choices.
> >
> > There’s one outstanding question, which is slightly painful to ask:
> > Originally, this RFC was called “property accessors,” which is the
> > terminology used by most languages. During early development, when we had
> > 4 accessors like Swift, we changed the name to “hooks” to better indicate
> > that one was “hooking into” the property lifecycle. However, later
> > refinement brought it back down to 2 operations, get and set. That makes
> > the “hooks” name less applicable, and inconsistent with what other
> > languages call it.
> >
> > However, changing it back at this point would be a non-small amount of
> > grunt work. There would be no functional changes from doing so, but it’s
> > lots of renaming things both in the PR and the RFC. We are willing to do so
> > if the consensus is that it would be beneficial, but want to ask before
> > putting in the effort.
> >
> Yes please ! Pass !
>
> I don't have voting rights, but we need this.
>
> Cheers,
>
> Pierre R.
I apologize if this has already been covered:
> There are two shorthand notations supported, beyond the optional argument to
> set.
> First, if a hook's body is a single expression, then the { } and return
> statement may be omitted and replaced with =>, just like with arrow functions.
Does => do any special auto-capturing of variables like arrow
functions or is it just a shorthand? Also, is this a meaningful
shorthand to the example a little further down:
public string $phone {
set = $this->sanitizePhone(...);
}
or do we always have to write it out?
public string $phone {
set => $field = $this->sanitizePhone($value);
}
Would __PROPERTY__ be set inside sanitizePhone() as well?
You mention several ways values are displayed (whether or not they use
the get-hook), but what does the default implementation of
`__debugInfo()` look like now (or is that out of scope or a silly
question?)
For attributes, it would be nice to be able to target hooks
specifically with attributes instead of also all methods (e.g., a
Attribute::TARGET_GET_HOOK const). For example, if I were writing a
serialization library, I may want to specify #[UseRawValue] only on
getters to ensure that only the raw value is serialized instead of the
getter (which may be specific to the application logic, or
#[GetFromMethod] to tell the serialization library to get the value
from a completely different method. It wouldn't make sense to target
just any method with that attribute.
