You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ReflectionClass::getStaticPropertyValue() returns UNDEF zval for uninitialized typed properties #12856
if the behaviour of ReflectionProperty::getValue() is desired, then the method should use BP_VAR_R instead of BP_VAR_IS (or just use zend_read_static_property_ex with silent=false)
otherwise the conditional in zend_std_get_static_property should be fixed to return a null pointer regardless of the BP_VAR_* mode.
It should probably throw to be consistent with getValue(), i.e. use BP_VAR_R. This would make the most sense to me. Getting NULL would be strange in this case especially when the type is not nullable...
But before I do anything: what do others think?
I agree that the recommendation in the manual should be changed or at least extended with ReflectionProperty::setValue(null, $value). I'm not really sure how it ended be like this.
Regarding deprecating ReflectionClass::(get|set)StaticPropertyValue(), I don't have a strong opinion. We could do that, but I can image that in some case it's easier to use this API than the ReflectionProperty one. If other people agree, we could add these methods to the PHP 8.4 deprecations RFC, but personally, I'm fine having the two APIs.
UPDATE: I've just (re-)realized that ReflectionClass::getStaticPropertyValue() doesn't have a proper default value either... So that serves as a motivation for me to either remove this API completely or just to remove the 2nd parameter + add a ReflectionClass::isStaticPropertyInitialized() method. But at this point it starts to look like a separate property API baked into ReflectionClass.... Which is not ideal.
It should probably throw to be consistent with getValue(), i.e. use BP_VAR_R. This would make the most sense to me. Getting NULL would be strange in this case especially when the type is not nullable...
But before I do anything: what do others think?
IMO this should either throw or return the default value ($default parameter). I lean towards the latter solution.
Activity
ndossche commentedon Dec 3, 2023
It should probably throw to be consistent with getValue(), i.e. use BP_VAR_R. This would make the most sense to me. Getting NULL would be strange in this case especially when the type is not nullable...
But before I do anything: what do others think?
ju1ius commentedon Dec 3, 2023
Why are there two APIs (
ReflectionClass::getStaticPropertyValue()vsReflectionProperty::getValue()) in the first place? Probably legacy?Then there is the fact thatReflectionProperty::setValue now raises a deprecation warning when used on static properties, and the docs officially recommend using an API that hasn't seen a commit in more than 3 years...
IMO this deprecation was a bad move.
ReflectionClass::(get|set)StaticPropertyValue()should have been deprecated instead.@kocsismate What do you think?
ju1ius commentedon Dec 3, 2023
After reading the deprecation RFC, I see that the new way to do this is
ReflectionProperty::setValue(null, $value).So there is an issue in the docs. The signature should be updated to reflect the nullability of the $object argument, and
instead of this:
It should say:
EDIT: see php/doc-en#2987
kocsismate commentedon Dec 3, 2023
I agree that the recommendation in the manual should be changed or at least extended with
ReflectionProperty::setValue(null, $value). I'm not really sure how it ended be like this.Regarding deprecating
ReflectionClass::(get|set)StaticPropertyValue(), I don't have a strong opinion. We could do that, but I can image that in some case it's easier to use this API than theReflectionPropertyone. If other people agree, we could add these methods to the PHP 8.4 deprecations RFC, but personally, I'm fine having the two APIs.UPDATE: I've just (re-)realized that
ReflectionClass::getStaticPropertyValue()doesn't have a proper default value either... So that serves as a motivation for me to either remove this API completely or just to remove the 2nd parameter + add aReflectionClass::isStaticPropertyInitialized()method. But at this point it starts to look like a separate property API baked intoReflectionClass.... Which is not ideal.kocsismate commentedon Dec 3, 2023
IMO this should either throw or return the default value (
$defaultparameter). I lean towards the latter solution.ndossche commentedon Dec 3, 2023
Default makes sense too, but then you can't distinguish between a non-existent property and one that exists but is uninitialized.
kocsismate commentedon Dec 3, 2023
Yeah, I'm fine with throwing an exception. It would make the removal of the default parameter easier. :)
iluuu1994 commentedon Dec 5, 2023
Tbh it seems odd to throw when there's an explicit
$defaultparameter. I realize that's not the original purpose of the parameter.That's true, although there is more fitting API to do so (i.e.
ReflectionProperty::isInitialized()).ndossche commentedon Dec 8, 2023
The way to go forward with this (exception / use default value) should probably be discussed on the mailing list.
Fix phpGH-12856: ReflectionClass::getStaticPropertyValue() returns UN…
Fix phpGH-12856: ReflectionClass::getStaticPropertyValue() returns UN…