Bug #78904 [PATCH]: Side-effects for uninitialised typed property

Edit report at https://bugs.php.net/bug.php?id=78904&edit=1 ID: 78904 Patch added by: nikic@php.net Reported by: public at grik dot net Summary: Side-effects for uninitialised typed property Status: Re-Opened Type: Bug Package: *General Issues PHP Version: 7.4.0 Block user comment: N Private report: N New Comment: The following pull request has been associated: Patch Name: Also don't call other magic for uninitialized typed properties On GitHub: https://github.com/php/php-src/pull/4974 Patch: https://github.com/php/php-src/pull/4974.patch Previous Comments: ------------------------------------------------------------------------ [2019-12-06 14:35:10] nikic@php.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. 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. ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ 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