Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Thu, Feb 22, 2024 at 1:03 AM Pierre 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.
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Wed, Feb 21, 2024 at 3:58 PM Larry Garfield
wrote:
> 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.
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
This is a long, huge and comprehensive work, congratz to the authors.
It clearly shows that so much thought and work has been put into it that it
makes me cautious to even ask for further clarification.
> Javascript have similar features via a different syntax, although that
syntax would not be viable for PHP
Why not?
```
final class Foo
{
public string $bar;
public function get bar(): string
{
// custom getter
}
public function set bar(string $value): void
{
// custom setter
}
}
```
It feels quite a natural syntax for PHP and from someone oblivious to the
internal work, it appears to be a slight marginal change to the existing
RFC. Given the extensive work of this RFC, it seems pretty obvious that
this syntax will not work, I just don't know why.
--
Marco Deleu
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Wed, Feb 21, 2024 at 12:57 PM Larry Garfield
wrote:
> 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.
>
Once again in reading the proposal, the first thing I'm struck by are the
magic "$field" and "$value" variables inside accessors. The first time they
are used, they're used without explanation, and they're jarring.
Additionally, once you start defining the behavior of accessors... you
don't start with the basics, but instead jump into some of the more
esoteric usage, which does nothing to help with the questions I have.
So, first:
- Start with the most basic, most expected usage for each of reading and
writing properties.
- I need a better argument for why the $field and $value variables exist.
Saying they're macros doesn't help those not deep into internals. As a
user, why do they exist?
Honestly, it's not obvious at all that I can just set something to the
variable "$field", and if I didn't know about the feature and stumbled
across a class that used accessors, I'd be wondering what "$field" is, and
how the property ever gets set. (And yes, I've read the FAQ. Saying it's
used in another language doesn't automatically make it good design.)
I know you say in the narrative that you _can_ use `$this->propertyName = `
to set the value, but you also say it's _not recommended_ (though you do
not indicate _why_). To somebody coming primarily from userland who's been
doing OOP in PHP for over 20 years, it's far more clear what's happening.
Alternately, I'd argue that both the accessors should require an argument
that represents the reference to the property:
public string $username {
set($field, string|Stringable $value) {
$field = (string) $value;
}
get ($field) => strtolower($field);
}
The same is true for $value. I'd recommend only ever allowing the construct
`set ($value) {}`, as it's immediately clear that `$value` is the argument
and value being provided to the accessor. When it's implicit, it's easy to
lose context.
Second: you don't have examples of defining BOTH get and set OTHER than
when using expressions for both accessors or a mix. I'm actually unclear
what the syntax is when both are defined. Is there supposed to be a `;`
terminating each? Or a `,`? Or just an empty line? Again, this is one of
the more common scenarios. It needs to be covered early, and clearly.
Third: the caveats around usage with arrays... give me pause. While I'm
personally trying to not use arrays as much as possible, a lot of code I
see or contribute to still does, and the fact that an array property that
uses a write accessor doesn't allow the same level of access as a normal
array property is something I see leading to a lot of confusion and errors.
I don't have a solution, but I worry that this one thing alone could be
enough to prevent the passage of the RFC.
Fourth: the syntax around inheritance is not intuitive, as it does not work
in the same way as the rest of the language. I'm talking about this:
public int $x {
get: 2 * parent::$x::get()
}
Why do we need to use the accessors here? Why wouldn't it just be
`parent::$x`?
I want to be clear: I really like the idea behind this feature, and
overall, I appreciate the design. From a user perspective, though, the
above are things that I found jarring as they vary quite a bit from our
current language design.
>
> 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.
>
I personally would go with just "accessors".
--
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
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.
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
It's really nice! >>> We are willing to do so if the consensus is that it would be beneficial, but want to ask before putting in the effort. I really think that it's not necessary, as the it still hooks into the default behavior of the properties. Even though I don't have voting privileges, I'm rooting a lot for it. Thank you again for this amazing work! -- Erick
[PHP-DEV] [RFC[ Property accessor hooks, take 2
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. -- Larry Garfield la...@garfieldtech.com
