Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126066
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 26 Nov 2024 14:35:29 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <b577a8ee-e5d9-49e6-a6be-e8bc9d5f4f19@app.fastmail.com>
In-Reply-To: <6bb0b82c31051ddf4c970ade616d532f@bastelstu.be>
References: <0addc1b4-1e4d-45a9-a289-5f9a8e1da692@app.fastmail.com>
 <6bb0b82c31051ddf4c970ade616d532f@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Static property asymmetric visibility
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Nov 26, 2024, at 3:57 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2024-11-25 17:52, schrieb Larry Garfield:
>> Static property asymmetric visibility was left out of the original RF=
C,=20
>> because it seemed like it would be hard and of little use.  Turns out=
,=20
>> Ilija found a way to make it easy.  (Ilija is smart.)  So here's a=20
>> small RFC to add aviz to static properties, because we can't think of=
 a=20
>> reason to NOT do so.
>>=20
>> https://wiki.php.net/rfc/static-aviz
>
> The RFC has the status =E2=80=9CDraft=E2=80=9D and does not appear to =
be linked in the=20
> overview at https://wiki.php.net/rfc. Is it intended to be open for=20
> discussion yet?

Paperwork oversight on my part.  Fixed now, thanks.

> Regarding the RFC contents: I am not sure the behavior of `private(set=
)`=20
> implying `final` is obvious for static properties. Consider this examp=
le=20
> (https://3v4l.org/bvQjM):
>
>      <?php
>
>      class Foo {
>          public static $baz;
>      }
>
>      class Bar extends Foo {
>          public static $baz;
>      }
>
>      Foo::$baz =3D '2';
>      Bar::$baz =3D '1';
>      var_dump(Foo::$baz, Bar::$baz);
>
> Non-static properties only have `$this->` for property access, but wit=
h=20
> static properties you can distinguish between `self::` and `static::`,=20
> which makes overriding a `private(set)` static property meaningful,=20
> because they are actually independent properties.
>
> Best regards
> Tim D=C3=BCsterhus

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? =20

--Larry Garfield