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
