get_class_vars contains a break change

[eerison]

Description

Hello guys, on php 8.1 + contain a break change, it should be the same behaviour for all php 8.x version, shouldn't it?

The following code:
https://3v4l.org/KRkS9#v

<?php
declare(strict_types=1);

class ExampleClass {
    public static bool $_strict = true;
}

ExampleClass::$_strict = false;

$example =  get_class_vars(ExampleClass::class);
var_dump($example);

Resulted in this output:

array(1) {
  ["_strict"]=>
  bool(true)
}

But I expected this output instead:

array(1) {
  ["_strict"]=>
  bool(false)
}

PHP Version

PHP 8.1+

Operating System

No response

[alecpl]

Documentation says: "Returns an associative array of declared properties visible from the current scope, with their default value". So, I suppose this was a bug fixed in 8.1.

[eerison]

Documentation says: "Returns an associative array of declared properties visible from the current scope, with their default value". So, I suppose this was a bug fixed in 8.1.

well I don't think so, if you check the link above, it is working since 7.4, on 8.1 it changed

[iluuu1994]

@eerison What Aleksander is saying is that the function is a misnomer:

get_class_vars — Get the default properties of the class

This function (apparently) is intended not to return the current values of the static variables, but their default values. This feature probably makes sense more for instance rather than static properties. Anyway, this behavior seems correct according to the documentation.

[eerison]

@eerison What Aleksander is saying is that the function is a misnomer:

get_class_vars — Get the default properties of the class

This function (apparently) is intended not to return the current values of the static variables, but their default values. This feature probably makes sense more for instance rather than static properties. Anyway, this behavior seems correct according to the documentation.

Ahhhh I got it

Yeah that's make sense, i guess this method was used like not recommended 🥲. Ok no problem I changed the implementation from my side.

But the question is, shouldn't it be used like this for others projects? Shouldn't it have some warning or deprecation message before change the behavior?

As you can see it works like this since 7.4, some informative message could save some hours of debug, it is a really tricky issue to find out 😅.

Maybe it should have deprecated on 7.4, but i guess no one was aware of it.

Well keep the same behavior makes the upgrades for minor versions smooth, But on the other hand I don't know if it worth the effort.

[iluuu1994]

@eerison I had another look and I think you might be right after all. It doesn't seem like this change was intentional, but implicitly changed as part of 4b79dba. We don't have a test like your test-case, which is likely why it was missed.

Nonetheless, given that the implementation has been like this for years at this point, and it matches the documentation, I'm not sure if fixing it doesn't cause more trouble than it's worth.

[eerison]

Maybe we could wait if someone else complain about this issue, if yes then we could reopen this issue, and fix it.

Because it is a really special case and it isn't documented.