get_class_vars() function does not work correctly with promoted properties.

[b-hayes]

Description

The following code:

<?php
class TryMe
{
    public function __construct(
        protected string $id,
        protected string $name = 'default name',
    )
    {
        var_dump(get_class_vars(static::class)); die();
    }
}

new TryMe( 'something' );

Resulted in this output:

array(2) {
  ["id"]=>
  NULL
  ["name"]=>
  NULL
}

But I expected this output instead:

array(2) {
  ["id"]=>
  NULL
  ["name"]=>
  string(12) "default name"
}

I thought promoted properties were supposed to be the same as regular properties and just save us some writing for initializations but it introduced breaking changes.

PHP Version

PHP 8.1.30

Operating System

No response

[DanielEScherzer]

get_class_vars is documented (https://www.php.net/manual/en/function.get-class-vars.php) as

Returns an associative array of declared properties visible from the current scope, with their default value

On the other hand, constructor property promotion is documented (https://www.php.net/manual/en/language.oop5.decon.php#language.oop5.decon.constructor.promotion) as

Default values on a promoted constructor argument will be replicated only to the argument and not the property.

So the default value of the class property is null, it is only the default of the constructor argument that is set

[b-hayes]

Still tho, its impossible for the property to be null ever. So how can that be the default?
If it was public and you accessed it youd get an "access before initialisation error", you can never get null.

The default value can and will only ever be whats in the promoted property declaration. Regardless of how its documented thats the behavour.

[iluuu1994]

null in this context not only indicates that the property may be null, but also that it may not have a default value. While this is indeed somewhat confusing and ambiguous, it's not unique to constructor promoted properties (https://3v4l.org/onjdo). It's also long-standing behavior, so any change would have to be discussed on the internals mailing list, and possibly go through the RFC process.

[b-hayes]

The default value is whats in the promoted property declaration, as that is whats going to be assigned once instantiated. There is no other way around it. Despite it not being "considered" the default, in practice it is.

If possible please suggest they consider making functions like this report the truth, and perhaps update their documentation because it certainly behaves this way in practice.

This function is effectively broken now that promoted properties exist.

$vars = get_class_vars(static::class);
        foreach ($vars as $name => $garbage) {// garbage value: can not be trusted in php8.1+
        // TODO: impliment complicated, slow and risky workaround viareflection to detect the use of promoted properties and ....

[iluuu1994]

As mentioned, promoted properties are just syntactic sugar.

class TryMe
{
    public function __construct(
        protected string $id,
        protected string $name = 'default name',
    ) {}
}

is exactly equivalent to:

class TryMe
{
    protected string $id;
    protected string $name;

    public function __construct(
        string $id,
        string $name = 'default name',
    ) {
        $this->id = $id;
        $this->name = $name;
    }
}

The default value specified in the promoted property is used for the parameter, but not the declared property. The rationale is explained here: https://wiki.php.net/rfc/constructor_promotion#desugaring

This function is effectively broken now that promoted properties exist.

Nothing would stop users from writing the desugared variant before constructor-promoted properties were a thing. So, this already wasn't possible to accurately detect in this way.

As any change is a BC break, this would need to be discussed on the mailing list. But you would also need to actually find a solution to the issues mentioned in the constructor_promotion RFC, or find some alternative approach.

[b-hayes]

Thanks for taking the time to reply.

Nothing would stop users from writing the desugared variant before constructor-promoted properties were a thing.

I see your point, you could declare a property with/without a default, and then have a default value in the constructor.

But you can not do this with promoted properties:

class TryMe
    protected string $test;
    public function __construct(
        protected string $test = 'hello',
    )
}
// results in: Fatal error: Cannot redeclare TryMe::$test

The promoted property is the only property declaration and its default value can be the only option as a property default.

This is also true:

class TryMe
{
    public function __construct(
        protected string $id,
        protected string $name = 'default name', 
    ) {}
}

is exactly equivalent to:

class TryMe
{
    protected string $id,
    protected string $name = 'default name'; //this part

    public function __construct(
        protected string $id,
        protected string $name = 'default name',
    ) {
        $this->id = $id;
        $this->name = $name;
    }
}

Maybe it wasnt intended to be this way but this is how it ended up right?

I dont see any problems that need solutions proposed other than to reflect what is really going on and consider the default value to be part of the property declaration.

Since its written as a property declaration with a default, and behaves as one, then seems a logical error not to reflect this.

If there are problems requiring alternative solutions please point them out as I cant see them other than, its too far gone now were in php8.3 and nobody addressed it earlier.

[iluuu1994]

Maybe it wasnt intended to be this way but this is how it ended up right?

The RFC that introduced promoted properties specifically mentions that the default value is declared only on the parameter, but not the property. So this was indeed intentional from the start.

I dont see any problems that need solutions proposed other than to reflect what is really going on and consider the default value to be part of the property declaration.

There are multiple issues to this.

• Since constructor-promoted properties are syntactic sugar, it's not possible to detect at runtime whether a property was declared through promoted properties, or manually through a property, a parameter and the corresponding initialization. Because of that, there would need to be some non-trivial logic to recognize whether a property is truly written to with the default value from the constructor. That said, flagging a property as promoted in a future version should be unproblematic.
• It's possible to circumvent constructors through ReflectionClass::newInstanceWithoutConstructor(), so your default value is not actually guaranteed in the same way as it would be with a true property default value.
• Adding this special handling just for get_class_vars() would mean it is inconsistent with ReflectionProperty::getDefaultValue().
• Changing the syntactic sugar to include the default value on the property itself is 1. LSP breaking, and 2. would break readonly properties, as they cannot include default values.

So, as you see this issue isn't completely trivial to solve, and certainly warrants a discussion. It's also unclear to me in the first place what the correct solution would be.

[b-hayes]

The RFC that introduced promoted properties specifically mentions that the default value is declared only on the parameter, but not the property. So this was indeed intentional from the start.

yeah I think thats a very confusing decision to come out and say you can now define the properties in the constructor, but only part of the definition works lol.

it's not possible to detect at runtime whether a property was declared through promoted properties

The interpretation of the syntactic sugar would need to be adjusted. Simply put, the property definition would be the same as the promoted property.

It's possible to circumvent constructors through ReflectionClass::newInstanceWithoutConstructor(), so your default value is not actually guaranteed in the same way as it would be with a true property default value.

This problem is only created buy not following the first solution above.

Adding this special handling just for get_class_vars()

again not a problem. solved by first solution.

1. LSP breaking

Not sure how. If it is then simply defining a default value on the property as well as a default constructor value is somehow lsp breaking too and this pre-dates anything we are discussing.

2. would break readonly properties, as they cannot include default values.

This is the problem. And it caused by an unnecessary restriction.

This would be addressed by first looking into why read only properties need to be this way and I imagine a similar discussion to this would unfold (if you'd humour me).

Because this:

class TryMe
{
    readonly string $id = 'cats';
    public function __construct(
        string $id = 'cats'
    ) { }
}

Is not a problem.
Default values suddenly appear if someone used reflection to bypass the constructor. And using a public read only property with no constructor is functionally redundant when they could use a constant.

But there is no reason for it to be illegal.

The only thing read-only should be preventing is assignment once instantiated.

Anyone using reflection can probably bypass this anyway breaking LSP and any other rules your trying to impose with your class definitions. I wouldn't cater to those edge case users.