Re: [RFC][Vote announcement] Property hooks

Hi Matthew We're going to skip over the reiterations of Juliettes arguments, as they have already been responded to. On Thu, Apr 11, 2024 at 12:08 AM Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote: > > On Mon, Apr 8, 2024 at 4:41 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote: >> >> https://externals.io/message/122445#122667 >> > > 2. I'm not a huge fan of the short syntax, but the improvements in the most recent draft > are _mostly_ ones I can live with. The part that's still unclear is when and where hooks need a > ; termination, and _why_ the ; is > used, instead of ,. When using > match() expressions, you use , to > separate the expressions, but for some reason, the proposal uses ; > ... but only when using short expressions. And if you have a full-form mixed with a short form, the > ; is only needed for the short-form expression. This feels > arbitrary, and it will be easy to get it wrong for people comfortable with Þ] > ‡æ¿Ä^2™Tœmmatch() statements. I agree that the distinction of , and ; isn't clear-cut. I would categorize hooks as declarations, because they are really just functions attached to the property. Declarations are ;-terminated, or have a body ({}) (properties, (non-)abstract methods, class consts, etc). ,, on the other hand, is used for lists of expressions and other things (array elements, match cases, function arguments). The other argument for the syntax we chose is that it's already used in C#. > (Larry tells me that it's match() being weird here, but > considering that for many developers, their only point of reference for this sort of syntax IS > match(), making it feel like the language is ignoring its own syntax > when creating new syntax.) Given my description from above, I don't believe this is true either. Match arms most closely relate to the array element syntax, which already uses ,. > 3. While I'd likely prefer Marco's approach to references (just don't allow > them), the fact that they mirror how __get() and > __set() _currently_ work gives a migration path for users who are > familiar with that paradigm's gotchas. In other words, it's consistent with the current > language, and will make migrating from __set/__get to hooks easier. > It's a lot of complexity, but the table you created helps with that. That table MUST make it to > the docs for the feature! Precisely. Our decision to support references (as much as possible) comes from the desire to maintain compatibility (as much as possible), not only with __get/__set but also plain props. Ilija