Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126203
Message-ID: <ba402e4d-51b4-4a4c-ae57-380563eb2e3e@gmail.com>
Date: Tue, 7 Jan 2025 19:38:59 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Static property asymmetric visibility
To: internals@lists.php.net
References: <0addc1b4-1e4d-45a9-a289-5f9a8e1da692@app.fastmail.com>
 <fdea1691-d1b6-44bb-88a7-71d0c0deb7bb@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <fdea1691-d1b6-44bb-88a7-71d0c0deb7bb@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
From: dossche.niels@gmail.com (Niels Dossche)

On 04/01/2025 00:14, Larry Garfield wrote:
> On Mon, Nov 25, 2024, at 10:52 AM, Larry Garfield wrote:
>> Static property asymmetric visibility was left out of the original RFC, 
>> because it seemed like it would be hard and of little use.  Turns out, 
>> Ilija found a way to make it easy.  (Ilija is smart.)  So here's a 
>> small RFC to add aviz to static properties, because we can't think of a 
>> reason to NOT do so.
>>
>> https://wiki.php.net/rfc/static-aviz
> 
> Heads up: Absent any other feedback, I'm going to call the vote on this RFC early next week.
> 
> --Larry Garfield

Hi

I'm not sure how I feel about this.
The current implementation actually uses a workaround because otherwise it interferes with cache slot merging.
This creates duplicated code in the VM handlers. Although the complication is small, it still is one. And the complication may be duplicated in the future in the JIT.
Workarounds/complications can be fine if having the feature is justifiable, but you said yourself that it seems of little use and the RFC text says it's just for completeness.
So honestly, I'm conflicted and leaning towards voting "no".

Kind regards
Niels