On Mon, Jun 10, 2024, at 19:51, Rodrigo Vieira wrote:
> I didn't like the Prefix-style syntax. I prefer the
> Hook-embedded-style syntax. First let's look at the counterpoints of the
> Prefix-style syntax:
>
> ## 1) "Prefix-style is more visually scannable"
> > The set visibility is 10 lines away from the get visibility!
>
> Solution:
> ```php
> class HookEmbeddedStyle
> {
> public string $phone {
> private set {
> $this->phone = implode('', array_filter(fn($c) => is_numeric($c),
> explode($value)))
> }
> get {
> if (!$this->phone) {
> return '';
> }
> if ($this->phone[0] === 1) {
> return 'US ' . $this->phone;
> }
> return 'Intl +' . $this->phone;
> }
> }
> }
> ```
> The set visibility is not 10 lines away from the get visibility if you put it at the top. For
> me this is about code convention, not about syntactic structure:
> only put the hook with explicit visibility at the top, when some of the hooks do not have
> explicit visibility!
>
> ## 2) "Prefix-style is shorter"
> ```php
> public private(set) string $name;
>
> public string $name { private set; }
> ```
>
> Irrelevant to consider 1-2 characters.
> If you break the lines needed for the hook block, the line (the horizontal size) is smaller
> when using Hook-embedded-style and in my opinion it is more readable because there is
> less information per line:
> ```php
> public private(set) string $name;
>
> public string $name {
> private set;
> }
> ```
>
> ## 3) "Prefix-style doesn't presume a connection with hooks"
> > As noted above in "Interaction with hooks", visibility controls exist
> > independently of hooks.
>
> I agree, but with Property Hooks, this should now define the overall visibility only. Like a
> bigger gate that you open, and there are other doors defining the visibility of the operations get,
> set (hooks).
>
> > In fact, as implemented, they don't interact at all. Using hook syntax for visibility
> > controls is therefore surprising and confusing.
>
> Why "surprising and confusing"? I see hooks as a different kind of function/method.
> Property Hooks RFC shouldn't pass without requiring hook parentheses, for any hook when
> the property is not abstract. The $value in the set hook seems to come out
> of nowhere to some people (the exception is for hooks declared on an abstract property which you can
> define without parameters and thus you are free to define whatever parameters you want on the
> concrete property).
>
> When you define a method in PHP, it should be possible to omit the "function", but
> the parameters should be required because that's the nature of a function/method: to have
> parameters.
>
> ## 4) "It's non-obvious in Hook-embedded-style what hook behavior should
> be implied"
>
> > ...So “arrays with hooks can do less” is already an established fact of the language.
> > However, if the hook-style syntax is used for visibility:
>
> ```php
> class A
> {
> public array $arr { protected set; }
> }
>
> class B extends A
> {
> public function add(int $val)
> {
> // Should this be legal?
> $this->arr[] = $val;
> }
> }
>
> $b = new B();
>
> $b->add(5);
> ```
> First of all: non-abstract property hook must have a body.
> Second: when asymmetric visibility is explicit, it means that symmetric visibility is implicit:
> a declared hook that does not have declared visibility has the same general visibility as the
> property, in this case: public.
>
> Third:
> There's another limitation on hooks here that makes things a bit confusing: there's a
> missing hook for a specific operation because you can clearly separate the set from the
> push operation...
>
> Solution:
> ```php
> abstract class A
> {
> abstract public array $arr {
> push; // Hook available only for "array" type properties only; public
> visibility
> private set;
> }
> }
>
> class B extends A
> {
> public array $arr {
> push ($value) { // public push ... here is redundant
> // Mandatory to implement logic here.
> }
> private set ($value) {
> // Mandatory to Implement logic here.
> }
> }
>
> public function __construct ()
> {
> // Legal ✅ (set hook is protected)
> $this->arr = [1]; // call set hook
> }
> public function add(int $value)
> {
> // Legal ✅ (push hook is public)
> $this->arr[] = $value; // call push hook
> }
> }
>
> $b = new B();
>
> $b->add(5);
> $b->arr; // Legal ✅ (Inherited from the general visibility that is public)
> $b->arr = [1, 2, 3]; // Fatal error ❌ - access to set hook is private only
> $b->arr[] = 4; // Legal ✅ - call public push hook
> ```
>
> My point: Prefix-style is not future-proof
> ## 1) The Prefix-style is not compatible with new hooks
> If more hooks are added in the future, such as the push hook for arrays or even a
> hook that is compatible with all types such as init, Hook-embedded-style
> will become compatible, but Prefix-style not.
>
> ## 2) Hook overloading
> If hook overloading is added in the future, Prefix-style would not be supported to
> have this granular visibility into operations. For example, it might be possible to add a public
> hook and a protected hook for the same operation, where one would be triggered if the operation
> occurred from outside the class, and the other if the operation occurred from inside the class.
> Em 10 de jun. de 2024 13:15 -0300, Tiffany <[email protected]> escreveu:
>>
>> On Wed, May 29, 2024, 2:16 PM Larry Garfield <[email protected]> wrote:
>>> As promised, Ilija and I offer this revised version of asymmetric visibility.
>>>
>>> https://wiki.php.net/rfc/asymmetric-visibility-v2
>>>
>>> It's still essentially the same as last year's version, but with a few
>>> adjustments and changes:
>>>
>>> * readonly properties are now supported in a logical fashion.
>>> * We've brought back the abbreviated form, as public-read, something else set is
>>> the most common use case.
>>> * The section on magic methods has been greatly simplified. The implementation itself
>>> hasn't changed, but the explanation is a lot less confusing now.
>>> * We've explained how aviz interacts with hooks (they don't, really) and with
>>> interface properties (in the obvious way), which didn't exist at the time of the last draft.
>>> * We've added a section with examples of how aviz is a concrete improvement, even
>>> in a world with readonly and hooks.
>>> * We've added a section discussing why the prefix-style syntax was chosen.
>>>
>>> *dons flame retardant suit*
>>>
>>> --
>>> Larry Garfield
>>> [email protected]
>>
>> Sending an email to quickly enable a new mailing list subscriber to engage in the
>> conversation.
I’m also not a fan of the prefix style, but for different reasons. My main reason is that it
increases the minimum line-length, potentially forcing you to chop things down into awkward looking
lines:
public
private(set)
string $longvarname {
get;
set;
}
I find that extremely hard to scan, but maybe others do not. The more natural looking syntax is
easier to scan and reason about (IMHO):
public
string $longvarname {
get;
private set;
}
If I’m having to read the code, I prefer to have everything near where it is used so I don’t
have to scroll up to the top and see its visibility. Granted, I haven’t used property hooks and I
have no idea how IDEs will help here; maybe it is a non-issue — but I guess people still have to
do code reviews which very rarely comes with IDE powers.
— Rob