On Thu, Nov 23, 2023, at 09:48, Nicolas Grekas wrote: > Hi Rowan, > > Le jeu. 23 nov. 2023 à 08:56, Rowan Tommins <rowan.coll...@gmail.com> a > écrit : > > > On 23 November 2023 01:37:06 GMT, Claude Pache <claude.pa...@gmail.com> > > wrote: > > >What you describe in the last sentence is what was initially designed and > > implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2 > > (section Overloaded Properties). > > > > > >However, it was later changed to the current semantics (unset() needed in > > order to trigger __get()) in https://github.com/php/php-src/pull/4974 > > > > > > Good find. So not only is it not specified this way in the RFC, it > > actually made it into a live release, then someone complained and we rushed > > out a more complicated version "to avoid WTF". That's really unfortunate. > > > > I'm not at all convinced by the argument in the linked bug report - > > whether you get an error or an unexpected call to __get, the solution is to > > assign a valid value to the property. And making the behaviour different > > after unset() just hides the user's problem, which is that they didn't > > expect to *ever* have a call to __get for that property. > > > > But I guess I'm 4 years too late to make that case > > > > Sorry this comes as a surprise to you but you're rewriting history here. > The current behavior, the one that was fixed in that commit, matches how > PHP behaved before typed properties, so this commit brought consistency. > > About the behavior, it's been in use for many years to build lazy proxies. > I know two major use cases that leverage this powerful capability: Doctrine > entities and Symfony lazy services. There are more as any code that > leverages ocramius/proxy-manager relies on this. > > About the vocabulary, the source tells us that "uninitialized" properties > that are unset() become "undefined". I know that's not super accurate since > a typed property is always defined semantically, but that's nonetheless the > flag that is used in the source. Maybe this could help with the RFC.
This. The lazy initialization use case is the only reason why we still allow declared properties to be unset at all. Our long term plan was to find an alternative way to support lazy initialization for properties, and then forbid calling unset() on declared properties. However, we still don't have that alternative today. Regards, Nikita
