[RFC] Static property asymmetric visibility

1 month ago by Larry Garfield — view source

unread

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

--
Larry Garfield
larry@garfieldtech.com

1 month ago by tim@bastelstu.be — view source

unread

Am 2024-11-25 17:52, schrieb Larry Garfield:

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

The RFC has the status “Draft” and does not appear to be linked in the
overview at https://wiki.php.net/rfc. Is it intended to be open for
discussion yet?

Regarding the RFC contents: I am not sure the behavior of private(set)
implying final is obvious for static properties. Consider this example
(https://3v4l.org/bvQjM):

 &lt;?php

 class Foo {
     public static $baz;
 }

 class Bar extends Foo {
     public static $baz;
 }

 Foo::$baz = '2';
 Bar::$baz = '1';
 var_dump(Foo::$baz, Bar::$baz);

Non-static properties only have $this-> for property access, but with
static properties you can distinguish between self:: and static::,
which makes overriding a private(set) static property meaningful,
because they are actually independent properties.

Best regards
Tim Düsterhus

1 month ago by Larry Garfield — view source

unread

Hi

Am 2024-11-25 17:52, schrieb Larry Garfield:

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

The RFC has the status “Draft” and does not appear to be linked in the
overview at https://wiki.php.net/rfc. Is it intended to be open for
discussion yet?

Paperwork oversight on my part. Fixed now, thanks.

Regarding the RFC contents: I am not sure the behavior of private(set)
implying final is obvious for static properties. Consider this example
(https://3v4l.org/bvQjM):
 &lt;?php

 class Foo {
     public static $baz;
 }

 class Bar extends Foo {
     public static $baz;
 }

 Foo::$baz = '2';
 Bar::$baz = '1';
 var_dump(Foo::$baz, Bar::$baz);
Non-static properties only have $this-> for property access, but with
static properties you can distinguish between self:: and static::,
which makes overriding a private(set) static property meaningful,
because they are actually independent properties.

Best regards
Tim Düsterhus

Hm, interesting point. I am not sure of the best way to model that.

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?

--Larry Garfield

1 month ago by Jonathan Vollebregt — view source

unread

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