Edit report at https://bugs.php.net/bug.php?id=78904&edit=1
ID: 78904
Updated by: nikic@php.net
Reported by: public at grik dot net
Summary: Side-effects for uninitialised typed property
-Status: Not a bug
+Status: Re-Opened
Type: Bug
Package: *General Issues
PHP Version: 7.4.0
Block user comment: N
Private report: N
New Comment:
> It would make sense to show a compile-time warning/notice for typed property declarations
> without initial value. Consider it for a later version, please.
Certainly not. There is nothing wrong with a property that does not have an initial value. In fact
nearly all properties shouldn't have one, as most properties get initialized based on
constructor arguments.
Based on preliminary discussion we might change __get() behavior, so I'm reopening this.
I'll prepare a patch asap.
Previous Comments:
------------------------------------------------------------------------
[2019-12-06 14:19:42] public at grik dot net
It would make sense to show a compile-time warning/notice for typed property declarations without
initial value. Consider it for a later version, please.
If it is not possible, consider adding the way to check if the property is initialized, so framework
authors could process this state in magic getters properly.
------------------------------------------------------------------------
[2019-12-06 14:01:05] nikic@php.net
So, sounds like we should have given __get() the same treatment as __set() in how it interacts with
uninitialized typed properties. I'm not sure if we can still make this change at this point.
------------------------------------------------------------------------
[2019-12-06 13:34:25] public at grik dot net
@requinix
Restricting access to uninitialised typed variable is OK.
The problem is having the __get() called.
@nikic Yes, I do have.
1. Consider a Request class from Laravel: https://github.com/laravel/framework/blob/master/src/Illuminate/Http/Request.php#L695
I extend it in an application to add custom behaviour, add a property. When the property is typed, I
have a __get() call executed from the framework class, which is unexpected, because it differs from
behavoir when the property has no type restriction.
2. __get() is extensively based in ORM implementations to map database data to the
"virtual" properties.
https://github.com/illuminate/database/blob/master/Eloquent/Model.php#L1552
When we define a userland class property named after the table field name, we expect the __get()
method not to be called.
Virtial public properties may be a bad practice, but it is promoted extensively in several
frameworks.
Having __get() called for uninitialized variables introduces a new variable state, and as such it
needs a way to be processed. Same as isset(), property_exists(), we need some property_initialized()
function.
------------------------------------------------------------------------
[2019-12-04 06:08:06] nikic@php.net
Do you have any particular (not quite so reduced) examples where this causes problems in practice?
We had some issues with __set interaction that were addressed, so possibly there is some tweak in
behavior possibly here as well, it's just not clear from the bug report what the actual issue
is.
But generally, yes, initializing typed properties is obligatory, that's part of the point of
having them. __get is called to allow some lazy initialization patterns, but shouldn't be
relevant for most purposes.
Is the issue here that __get is called instead of immediately throwing a "trying to access
uninitialized property" error?
------------------------------------------------------------------------
[2019-12-03 22:40:37] requinix@php.net
Works as intended. https://wiki.php.net/rfc/typed_properties_v2
Typed properties are never initialized to a default null, unlike untyped properties. That is why $y
and $z do not show up through get_object_vars: they are uninitialized. No, it cannot simply return
null because (a) the properties do not have the value of null and (b) null may not even be a valid
value for the property.
And as happens in some other languages, accessing an uninitialized property is not allowed.
As for the fatal error,
* ->y triggers __get, which returns null, which is valid for the "?string" type. No
error.
* ->x triggers __get, which returns null, which is not valid for the "string" type.
Error.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=78904
--
Edit this bug report at https://bugs.php.net/bug.php?id=78904&edit=1