Will the alternative syntax on hook not even be put to a vote?
I think the "prefix-style" syntax breaks the standard property signature template that exists since PHP 5!
Natural syntax:
<visibility> <types> $<name>;
With prefix-style:
<visibility> <visibility>(set) <types> $<name>;
This introduces a syntax that is totally unexpected to natural reading. In my opinion, pretty ugly.
What about some static code analysis tools? What about using regex to parse code and syntax in PHP (which takes a lot of work to build) for extensions used in IDEs like VSCode, IntelliJ, etc.?
To parse Property Hooks, a lot of time and work will already be spent adapting to the new syntax, and now this as well? Why not take advantage of the new Property Hooks syntax newly implemented?
Implementing visibility in the hook, which can be now the default API of the properties, would further enhance the syntax of Property Hooks, which in my opinion is one of the best features of PHP in the past five years.
If more operations on Hooks are implemented in the future, what is the use of this syntax? How could it be used? For example, an operation that is called only when a property is first set: `init` hook.
public $prop {
private init => //...set a default initial value here
}
A hook called 'push' only for arrays, would solve some semantic problems and make it clear to separate the set operation (set values of an array) vs push only one item to the array as I showed in the example above.
What about other operations that are already common when we use magical methods in the future: unset, isset, etc.?
In the Property Hooks RFC, it was mentioned that more hooks may be added in the future.
It may be a default behavior for developers to want to override all magic methods for properties using Property Hooks. For now there is only get and set, but what about unset, isset, etc? How is it to define the visibility for this in the future?
public private(set, unset)....
??
Where would new operations beyond the `set` will enter this syntax?
Cheers,
Rodrigo Vieira
Em Jul 19, 2024, 10:18 PM -0300, Larry Garfield <larry@garfieldtech.com> escreveu:
On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote:
> As promised, Ilija and I offer this revised version of asymmetric visibility.
>
> PHP: 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.
Hi folks. After a side quest to polish off hooks, we're nearly ready to bring aviz to a vote.
We've made one change since we last discussed it: Specifically, Ilija realized that __set's behavior is already inconsistent, so supporting it for aviz properties with invisible set would make it even more inconsistent, not less. For that reason, we've changed the __set behavior such that a non-readonly aviz property will not trigger __set. Further details are in the RFC, but in short, all of the use cases for that behavior now have better alternatives, such as property types, hooks, and aviz itself. So there's really no point to falling back to __set in edge cases.
PHP: rfc:asymmetric-visibility-v2
Baring any new developments, we plan to start the vote early next week.
Cheers.
--Larry Garfield