Typed property /w magic __get cannot be uninitialized

[mvorisek]

Description

demo: https://3v4l.org/lDeXi

Currently, typed property can be "almost uninitialized" by unset().

But doing such uninitialization unsets the property and allows magic __get to kick in. This is expected and discussed in #9021.

Because of this, non-readonly typed property cannot be uninitialized properly. This is an issue in cases when the same object is to be restored, reused or cleaned.

To allow an object state to be restored/uninitialized correctly, I propose to add ReflectionProperty::setUninitialized() method and backport it into PHP 8.0 and above.

[iluuu1994]

That message indeed look fishy. I'm not even sure if the type check is intentional. I'll check the RFC and implementation later.

[iluuu1994]

Meant to comment this on the other issue.

[mvorisek]

Meant to comment this on the other issue.

Yes, the wrong message issue is reported in #9388.

I'll check the RFC and implementation later.

The __get return type validation againt typed property is mentioned in https://wiki.php.net/rfc/typed_properties_v2#overloaded_properties. This is also how php works currently.

However there is also:

If a typed property is in uninitialized state, either because it has not yet been initialized, or because it has been explicitly unset(), then reads from this property will invoke the __get() method if it exists, consistently with the behavior of ordinary properties.

Currently this is not true. If property is "defined, uninitialized but not unset", Typed property Cl::$name must not be accessed before initialization error is shown. I personally like the current behaviour as __get magic is not invoked when property is defined but not initialized. The proposed ReflectionProperty::setUninitialized() reflection method does not impose any BC break and is consistent with ReflectionProperty::isInitialized() method used to check if a property is initialized or not.

[iluuu1994]

The __get return type validation againt typed property is mentioned in https://wiki.php.net/rfc/typed_properties_v2#overloaded_properties. This is also how php works currently.

Ah right. That makes sense.

Currently this is not true

Yes, but as you mentioned it was changed deliberately after the RFC has been voted on. f1848a4

IMO unsetting typed properties and keeping them unset sounds like a bad idea, as now any property access might succeed throw just one dubious method call later (with this behavior, that is). The inconsistency with __get is unfortunate, but IMO it would be better to disallow unsetting typed properties entirely.

So personally I'd rather see that gone, but others might disagree. According to f1848a4 this was only added as a workaround for ORMs anyway.

This gives us both the behavior people generally expect, and still allows ORMs to do lazy initialization by unsetting properties.

I don't quite understand why that would be needed though.