Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119810
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-238-g746678b8b6-fm-20230329.001-g746678b8
Mime-Version: 1.0
Message-ID: <19279c3e-b74c-4a7c-9f0b-d456c9259406@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LDK8Bc3y9vYQ+hN1Nt5XO8gXNSsbxqBAxKW5hHCYFORPg@mail.gmail.com>
References: 
 <CAPyj-LDK8Bc3y9vYQ+hN1Nt5XO8gXNSsbxqBAxKW5hHCYFORPg@mail.gmail.com>
Date: Fri, 31 Mar 2023 13:12:11 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Traits and redeclaring static properties
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Mar 31, 2023, at 1:07 PM, Ilija Tovilo wrote:
> Hi everyone
>
> A few days ago we received a bug report about an inconsistency with
> traits and static properties.
>
> https://github.com/php/php-src/issues/10935
>
> https://3v4l.org/Dll1m
> ```
> class A {
>     static $test;
> }
> class B extends A {
>     static $test;
> }
> A::$test = 'A';
> B::$test = 'B';
> var_dump(A::$test, B::$test);
> // string(1) "A"
> // string(1) "B"
> ```
>
> https://3v4l.org/SClLn
> ```
> trait Foo {
>     static $test;
> }
> class A {
>     use Foo;
> }
> class B extends A {
>     use Foo;
> }
> A::$test = 'A';
> B::$test = 'B';
> var_dump(A::$test, B::$test);
> // string(1) "B"
> // string(1) "B"
> ```
>
> To summarize, a trait does *not* add a property to a class that has
> already inherited the same property from its parent. This makes sense
> for non-static properties, as redeclaring the property essentially has
> no effect. For static properties, however, there's a semantic
> difference in that redeclaring a static property creates a new slot in
> the current class that is separate from the parent's static property
> slot.
>
> This was never explicitly specified by the traits RFC. However, this
> sentence hints at the fact that the two examples above should behave
> equivalently.
>
> https://wiki.php.net/rfc/horizontalreuse
>> It is almost like a language supported and failsafe copy'n'paste mechanism to build classes.
>
> I created a PR to align the behavior of the two examples. It targets
> the master branch to avoid any potential backwards incompatibility in
> a patch.
> https://github.com/php/php-src/pull/10937
>
> Please let me know if there are any concerns about this change.
>
> Ilija

This seems reasonable to me.  "Compile time copy and paste" is the mental model we've been training people to have for a decade, so ensuring it actually works that way in corner cases seems like the right move.  I don't think I've ever seen code that would have a behavior change as a result.

--Larry Garfield