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 <tiffany.k.tay...@gmail.com> > escreveu: >> >> On Wed, May 29, 2024, 2:16 PM Larry Garfield <la...@garfieldtech.com> 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 >>> la...@garfieldtech.com >> >> 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