On Thu, Jun 17, 2021 at 11:53 AM Côme Chilliet < come.chill...@fusiondirectory.org> wrote:
> Le Wed, 16 Jun 2021 10:16:37 +0200, > Nikita Popov <nikita....@gmail.com> a écrit : > > > 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. > > If option 3 is considered, it means the evaluation order may change, if we > can > change the evaluation order, why not go for option 1? I do not understand > which > existing code can break with option 1 and be fine with option 3, it means > this > code relies on undefined behaviors, no? > See the example in https://externals.io/message/113347#113642. I'm not sure how common this is, but I expect this kind of pattern does get used in PHP code not using autoloading and declaring multiple classes perf file. What this relies on is not so much that evaluation happens at a specific place, but that it doesn't happen during initial class declaration, which is exactly the assumption that would be broken by option 1. Regards, Nikita
