On Fri, Jun 17, 2022 at 1:46 AM Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> Even without __get the property of an object referenced in the LHS of > The engine evaluates the default property > values once for the entire class and then copies the result whenever a > new instance of that class gets created. That means further instances > will use the out-dated property default value from when the first > instance was created. Similarly, function default parameters get > cached between calls. We could evaluate the constant expression for > each object instantiation or function call but degrading performance > for an edge case doesn't seem worth it. > > Hey Ilija, I really think we should have the same limitations for "->" and "?->" just like we have for "new", with the same reason that that was disallowed. That would mean not allowing it in the default values of a property. Maybe I'm missing something but it looks like this was the plan all along as you don't have any example that would include that, neither in the RFC or in the PR tests. The only case you mentioned and that's only in the RFC itself, not in PR tests is the class constant for enums. I'm not even sure that is working with the current implementation. IMHO, allowing the fetch property operator in the 4 places where new is allowed would be a simple good step forward. There was the discussion where allowing it in attribute arguments is important for allowing cross boundaries transforming from enum to string: https://github.com/php/php-src/pull/8825#issuecomment-1161735119 An option to limit it to enums in the other 3 places, static or instance property initializers and class constant initializers while allowing it on all objects in the 4 cases where new is allowed. Or yeah, limit to enum in all 7 cases, if that is a lot simpler. I wouldn't prefer it as I still have cases in mind where I'm not dealing with enums but it's your call. Thank you, Alex
