Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122481
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848
Precedence: bulk
MIME-Version: 1.0
Message-ID: <11e3cb04-fe63-4931-94f1-0ef2e414d309@app.fastmail.com>
In-Reply-To: <8dddf382-6904-46d3-98e4-65cdc6892d31@mabe.berlin>
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <CAJp_myUayeQ=irpFUG0OrUj=PjE3_mx395h_ARSdLmdyEB6_EQ@mail.gmail.com>
 <790b5b4e-f51b-4050-a12a-5fa903d0568f@app.fastmail.com>
 <8dddf382-6904-46d3-98e4-65cdc6892d31@mabe.berlin>
Date: Fri, 23 Feb 2024 20:37:58 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Feb 23, 2024, at 5:35 PM, Marc Bennewitz wrote:
> Hi Larry,
>
> first of all thank you very much for this amazing work you two have been 
> done :+1:.

> 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.

Making everyone type ": void" after every set hook, when we already know that's going to be the case, seems like a really bad developer experience.

I talked with Ilija extensively about it, and there is no meaningful way to distinguish between "this method returned null" and "this method didn't return" from the call site in the engine.  If we could, that would allow smarter detection of when it makes sense to use a return value.  Hence my suggestion of allowing set-on-return only for the => form.

> 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?

$field has already been removed.  See previous email.

--Larry Garfield