Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126068
Message-ID: <18eebe54-569d-4300-9e9f-4511ca9a60df@jnvsor.net>
Date: Tue, 26 Nov 2024 22:42:23 +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>
 <6bb0b82c31051ddf4c970ade616d532f@bastelstu.be>
 <b577a8ee-e5d9-49e6-a6be-e8bc9d5f4f19@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <b577a8ee-e5d9-49e6-a6be-e8bc9d5f4f19@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-mijn.host-Spamfilter-Domain: mijn.host
X-mijn.host-Spamfilter-Username: 2a03:5180:7:2:f264:726d:beae:1/112
Authentication-Results: mijn.host; auth=pass smtp.auth=2a03:5180:7:2:f264:726d:beae:1/112@mijn.host
X-mijn.host-Spamfilter-Outgoing-Class: ham
X-mijn.host-Spamfilter-Outgoing-Evidence: Combined (0.27)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/ptDXMD9mL08aGHi6lS7nePUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5ysVpdc69k5cRExqclQnUjJ0xCugIxICoR4SK4EpYmU4+fH
 zJ6mVE7ewsipSVIfs4bMdHevLUOQOQc0AaYI/g9AABHVTw1lV42ob3hDgXVUNd9a53XVj4zauHkA
 5dPfA2liT1v1qMyQrE//74nL7QExIgxyuxk9omAUfu9FIr1FSQRo87oeATC+hGtbNyLqD79d1FgH
 UTYLOfKNI261jSzBP06AR5g2UA3HqsYlcMd+kU3FrKlNunbw3GCGM2ilT87d7j7SBq6MwVj6lFM1
 1vq969CCDfOKd5FAllGsCCg+XysEJGdAAQBUErof8jiNd96dw+XGlIW1bb6iLQaqIs5B5d+hLlId
 aCW6xwdNo4OxtwDY4SpTbUhcsSYcTjOB+M5x3dBtceKX2dWiEm+7oHm9xBEeGmns8QeFADnQDTrf
 rserYKXCRGR18OfTWrHpf6kV0xJ411PPMPVAmEodS0dereVcnHDGPTHJJ/+YucHWLMPH12Bh87aa
 4YfZs104p87OifVovUq7COge14oi3y0trSOIPpeqwlm2NDGXIJ2x7Aw67nLpfFALWaP7S/uCvcMs
 T3AdBmqsjHpFvIRGv3QGFGGN9tupvM6WO2Ft1gH+FQ7gxDBYNWtge7riHAeQ7vclA5yvuKg/VrQW
 W0t2gQb8VPATXlXOfRp8+eB3Yg8HXdFEFdiL9rNiZMnOwdYHLGEeFcyQ7VJExC7Q4eRzWD0n0z6b
 halFEM/pjPCQA+BAlk5KEOURO6sk/Aa437Ns/uqKg2woREVyMtyJFnDS+FlbfzX2Upc4UYfakoa5
 bzcIyGjsjFy0EQbbJzDJS/5nWWzfRmo+6HsrDTfTk2WASpxA9hnDZXV2CQwQLTmDKYV0FLstv/fQ
 2PQkRKCR50pYUO1+pvlHhV6a5QjptwQBGybQa79B8ofWhEiU8433QvQjH6EsmgNU80KTDQcWwe0S
 4mArfQ+tROiiWG4K9sxAvhAB5OBSN81tpz7T+tfAQe1JK2MgYyDjTfyYIHhsZr9+GI4gfKNLQ72k
 P6B93hdHavZ5
X-Report-Abuse-To: spam@filter101.mijn.host
From: jnv@jnvsor.net (Jonathan Vollebregt)

On 11/26/24 9:35 PM, Larry Garfield wrote:
> Thinking aloud, my expectation would be that it behaves similarly to how final static methods would behave.  Which appears to be a syntax error:  https://3v4l.org/j8mp0#v8.4.1
> 
> So, shouldn't properties do the same?

Without final you can still override both private static properties and 
private static methods: https://3v4l.org/MS73Y#v8.4.1

When explicitly declared final, static properties do result in a syntax 
error: https://3v4l.org/fqI8v#v8.4.1

Re-reading the logic in the original aviz RFC makes me think implicit 
final here is unnecessary. All static properties are "Shadowed" like 
private properties (even when they're public) so there's no conflicting 
behavior.

The two behaviors described as conflicting in the aviz RFC are decided 
explicitly in the context of static properties, by the caller accessing 
it with `self::` or `static::`. Not by a combination of the visibility 
and child classes.

Consider this example:

```
class A {
     private(set) static int $a = 1;

     public static function test(int $val) {
         static::$a = $val;
     }
}

class B extends A {
     private(set) static int $a = 2;
}

B::test(3)
```

Yes this would produce a fatal error, but doing this with just `private 
static` does the same in current PHP: https://3v4l.org/Y6lZ7#v8.4.1

You might want to discuss banning use of `static::` on private statics, 
but that's a big BC break.

Since static properties do still have to have equal or wider visibility 
when extending I'd say using `static::$prop` on a property you know is 
private is a known risk and remove the implicit final.

- Jonathan