On Wed, Jun 16, 2021, at 3:16 AM, Nikita Popov wrote: > > Arguments and attributes are enough to justify this RFC on its own, but is > > there a way we can resolve the static property question? Right now the RFC > > says "these initializers are evaluated lazily the first time a class is > > used in a certain way." Can you be more specific about that certain way? > > Is there a certain way that would be minimally disruptive? > > > Well, here is a non-exhaustive description of current behavior: > > * If you access a class constant, only that constant is evaluated. > * If you access a static property, all initializers in the class and > parent classes are evaluated. > * If you instantiate a class, all initializers are evaluated. > * Inheriting from a class or calling a static method doesn't evaluate > anything. > > As you can see, the rules are rather ad-hoc. To the user, it's probably not > obvious why instantiating an object of a class would require evaluating > class constants at that point. The reason is that instantiation requires > resolved property defaults, and we happen to evaluate all initializers at > once. > > The options where static properties and class constants are concerned are: > > 1. Eagerly evaluate initializers on declaration. This is what I tried in an > earlier revision of the RFC, and I don't think that approach works. It > breaks existing code and has various other unpleasant complications. > 2. Precisely specify the current behavior. I don't want to do this either, > because the exact places where evaluation happens are something of an > implementation detail. If in the future we find it convenient to separate > evaluation of non-static properties on object instantiation from evaluation > of static properties and class constants (which are not strictly needed at > that point), I'd like to retain the liberty to make such a change. > 3. Do not specify an evaluation order, beyond that evaluation happens at > certain uses of the class. Evaluation order may change across PHP versions. > If your code relies on any particular order, your code is broken. > > Unless I'm missing a fourth option here, option 3 is the only one I would > be willing to go for at this time.
Thanks. To clarify, the concern about evaluation order is only relevant if you are initializing a class whose constructor has some kind of side effect, right? Writing to disk or printing or something like that. Otherwise, at worst you may initialize a few more objects than you expect there should be no behavioral change. Given that constructors that have side effects are arguably broken to begin with (modulo debugging), I'd be comfortable with explicitly saying that the evaluation order is undefined, and nothing is guaranteed except that the value will be there when you first access it. In the future, if function initializers or something like that are added we can revisit that question, though I would be tempted to say the same thing in those cases; if you want to do some kind of DB read in a function that is a default value for a property or a parameter, frankly odds are you're already doing something wrong to begin with. But that's a bridge we can cross if and when we get to it. Would others be comfortable with that, if it allowed new-initializers for static properties and class constants? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
