On Thu, Jun 17, 2021 at 11:53 AM Côme Chilliet <
come.chilliet@fusiondirectory.org> wrote:
Le Wed, 16 Jun 2021 10:16:37 +0200,
Nikita Popov <nikita.ppv@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?
. 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
Is this a case where we go for the current scope in 8.1 and then extends