Re: [RFC[ Property accessor hooks, take 2

Hi Larry, first of all thank you very much for this amazing work you two have been done :+1:. On 23.02.24 00:56, Larry Garfield wrote:

On Wed, Feb 21, 2024, at 11:02 PM, Matthew Weier O'Phinney wrote:

On Wed, Feb 21, 2024 at 12:57 PM Larry Garfield <larry@garfieldtech.com> 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?

For $field, it's not a requirement. It's mostly for copy-paste convenience. A number of people have struggled on this point so if the consensus is to leave out $field and just use $this->propName directly, we can accept that. They can be re-added if reusable hook packages are added in the future (as noted in Future Scope).

I'm also feeling that introducing magic variables isn't the best design choice. I read your section about "Why do set hooks not return the value to set?" and I don't really agree. Let me explain ... 1. Virtual properties and technically all functions return a valid. I think it would me much less magic if property setters on virtual properties declare a void return type. This would make it very obvious that this is a virtual property even on having to read complex setters. 2. it disallows any action /after/ the assignment happens I actually think this would be a good think! An object property should only be set after everything has been done. If you want to do more it should either not be part of the setter or you should use a temporary variable what you have to do anyway to not leave your object in an incorrect state. Let's say we have the following setter: public string$name {

    set($value){ // do stuff
        $field = $value; // or $this->name = $value
        // do more stuff and (eventually) fail
        throw Exception();
    }

} try {

    $object->name = 'test';

} finally {

    $object->name; // what is name here ?

} 3. ambiguity I actually feel that $field is ambiguous. What happens if you declare set($field) {} ? Does such construct let the engine set the property value immediately as the input value gets immediately assigned to the property via $field? Greetings, Marc

Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0x3936ABF753BC88CE.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc