On Wed, Mar 3, 2021 at 4:28 PM Alexandru Pătrănescu <dreal...@gmail.com> wrote:
> Hi, > > This looks very nice and I'm interested in further steps where not only > new can be used :). > > The only thing I think it would be good to improve is to have a > deterministic order for running initialization. > Yes, this can be done at a later point, I guess. But maybe there is > already an order of initialization right now and people would start > replying on it and it would be good to mention it. > Or maybe I didn't understand what this refers to: "this is not guaranteed > behavior, and code should not rely on a specific point of evaluation." > Which particular cases would you like to see specified? There are five cases that have clearly defined behavior, and that I could explicitly specify if desired: * Non-class constants: Are evaluated immediately when declared (i.e. when control flow reaches the declaration). * Attribute arguments: Are evaluated in the order of the arguments. * Parameter defaults: Are evaluated in the order of the parameters. * Non-static property defaults: Are evaluated in order of declaration, with parent properties first. The constructor is run after defaults are evaluated. * Static variables: Are evaluated immediately when declared (i.e. when control flow reaches the declaration). And then there are the two problematic cases: Class constants and static properties. Currently, PHP evaluates these semi-lazily. All class constants and static properties are evaluated at the same time, on first "use" of the class. I would consider this to be something of an implementation detail. That's what I meant by that sentence. Now, if we allow "new" expressions, then I could see an argument in favor of requiring class constant and static property initializers to be evaluated eagerly, i.e. directly after the class has been declared. This would be a (minor) backwards-compatibility break, because invalid constant/property declarations would error out immediately, even if they don't get used. However, I do think that this would be the most predictable behavior once potentially side-effecting expressions are involved (we already support side-effecting expressions right now, but less explicitly). Regards, Nikita Also, in > https://wiki.php.net/rfc/new_in_initializers#evaluation_of_expressions > I think that for the static initialization the text should say "are > evaluated once." instead of "are evaluated once per request." so we are > more general, including CLI cases. > > I'm used with dynamic initialization coming from other languages, learning > it in Java 13-14 years ago, including the clearly defined order of > initialization. > > Regards, > Alex > > > > On Wed, Mar 3, 2021 at 5:04 PM Nikita Popov <nikita....@gmail.com> wrote: > >> Hi internals, >> >> I would like to propose allowing the use of "new" inside various >> initializer expressions: https://wiki.php.net/rfc/new_in_initializers >> >> In particular, this allows specifying object default values for properties >> and parameters, and allows the use of objects as attribute arguments. >> >> The RFC is narrow in scope in that it only adds support for "new". An >> extension to other call kinds should be straightforward though. >> >> Regards, >> Nikita >> >
