Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114371
MIME-Version: 1.0
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <CAAwdEzApyQd52RpJ-gW+pNtBA=jA1bn74c-K1djcztRRgaYAag@mail.gmail.com>
 <CAF+90c8YMpGNLKehfFW6gWJx0mGUVqL0Rx+U262gGRP6cTXBgw@mail.gmail.com>
 <CAAwdEzDwD5sc6AQxLSnj0Dx=4ZsP1h0K83TS+jyN1x5_X7NAAg@mail.gmail.com>
 <CAF+90c9_=GkKbErf-z464_zqAHCDERbdLjd_uyoNvC9PERxoxQ@mail.gmail.com>
 <CAF+90c_WVD3jDtrtVbAuPGPWf9v6Hz4h2i=nrgHi+4Axx4157Q@mail.gmail.com> <CAF+90c9WXzqVnJ-U6Sj=xP39rEn03FDksdLG85T=e_+ZhdCXTA@mail.gmail.com>
In-Reply-To: <CAF+90c9WXzqVnJ-U6Sj=xP39rEn03FDksdLG85T=e_+ZhdCXTA@mail.gmail.com>
Date: Tue, 11 May 2021 11:56:36 +0200
Message-ID: <CAF+90c_YSo_W6twktGg0nZ16Tr+qx_xsEucsOSdh6=uS8kTSAQ@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d6635805c20ae951"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d6635805c20ae951
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 19, 2021 at 2:02 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Fri, Mar 19, 2021 at 12:57 PM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> On Fri, Mar 19, 2021 at 12:22 PM Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>
>>> On Wed, Mar 3, 2021 at 7:04 PM Alexandru P=C4=83tr=C4=83nescu <drealecs=
@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Wed, Mar 3, 2021 at 5:49 PM Nikita Popov <nikita.ppv@gmail.com>
>>>> wrote:
>>>>
>>>>> On Wed, Mar 3, 2021 at 4:28 PM Alexandru P=C4=83tr=C4=83nescu <
>>>>> drealecs@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 fiv=
e
>>>>> 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 aft=
er
>>>>> 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 cl=
ass
>>>>> constants and static properties are evaluated at the same time, on fi=
rst
>>>>> "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. T=
his
>>>>> would be a (minor) backwards-compatibility break, because invalid
>>>>> constant/property declarations would error out immediately, even if t=
hey
>>>>> don't get used. However, I do think that this would be the most predi=
ctable
>>>>> behavior once potentially side-effecting expressions are involved (we
>>>>> already support side-effecting expressions right now, but less explic=
itly).
>>>>>
>>>>>
>>>> Yes, this is what I was thinking about, to have a clear stated order o=
f
>>>> initialization.
>>>> Yes, I agree that class constants and static properties should be
>>>> eagerly declared when class is declared.
>>>>
>>>> So the order would be:
>>>> - constants and static variables, when reaching the statement that doe=
s
>>>> the declaration
>>>> - class constants and static property, when class is declared, in orde=
r
>>>> of their declaration in the class
>>>> - instance property, when class is instantiated, in order of their
>>>> declaration in the class, before construct
>>>> - parameter defaults and attribute arguments defaults, when
>>>> function/method/attribute construct is called, in order of the declare=
d
>>>> parameter/arguments.
>>>>
>>>> That sounds good to me.
>>>> Thanks!
>>>>  Alex
>>>>
>>>
>>> I've updated the RFC (and implementation) to evaluate class constants
>>> and static properties at time of class declaration. As such, everything
>>> should have a well-defined evaluation order now.
>>>
>>> However, this also means that this RFC now also contains a
>>> backwards-compatibility break: Anything used inside class constant / st=
atic
>>> property initializers needs to actually be available at the time the cl=
ass
>>> is declared. You can't first declare the class, then declare some
>>> additional constants it uses, and then use it.
>>>
>>
>> Another complication here is preloading. The current semantics of
>> evaluation on first use work well there, because class loading (during
>> preloading) is decoupled from evaluation (during request). Now, we can't
>> evaluate initializers during "opcache_compile_file" style preloading, so
>> we'd have to delay this to the start of the request. And then we'd have =
to
>> evaluate initializers for all preloaded classes, regardless of whether t=
hey
>> will be used in this particular request or not. Also opens up the questi=
on
>> of the order in which the classes should be evaluated.
>>
>> I initially liked the idea of evaluating everything at the time of class
>> declaration, but now get the impression that this causes more problems t=
han
>> it solves, and we should go back to the previous lazy evaluation approac=
h.
>> Ultimately, my view here is that side-effecting constructors are a terri=
ble
>> idea, and if you use them then you should also carefully manage those
>> side-effects yourself.
>>
>
> Just to throw it out there, another option would be to not support "new"
> for static properties and class constants, where the semantics are less
> clear cut than in all the other cases. For me personally the important us=
e
> cases here are initializers for non-static properties and parameters, as
> well as attribute arguments, and those all have unambiguous semantics. Of
> course, there is also a lot of value in having consistent support.
>

An issue for using new in (non-static) properties is that these objects are
going to get created even if the constructor doesn't run. This could be a
problem for things like unserialize() and anything that implements related
functionality in userland (e.g. Symfony's VarCloner). In particular, this
means that the default is *always* going to be constructed and populated,
even if you're bypassing the constructor. Of course, this also happens with
other property defaults, but in this case object construction may be more
expensive (and possibly side-effecting). That's not great, and there
wouldn't really be any way to avoid that.

The alternative would be to instead only initialize such properties in the
constructor, which comes with its own caveats: We'd have to make all
classes actually have a constructor, and you'd have to make sure to call
parent::__construct() even if there is no explicit parent constructor,
otherwise you might be missing some property initializations. This also
causes something of an asymmetry between "simple" default values
(initialized on object creation) and "complex" defaults (initialized during
constructor call).

TBH, I'm not quite sure what to do with this RFC. I'm considering whether
it may make sense to cut it down to the bare minimum, which is support for
new inside parameter defaults and attribute arguments (and possibly global
constants and static variables -- I don't think those have any issues, but
they're also not terribly useful). Parameter defaults happen to also cover
the common case of property defaults, through constructor promotion. This
would still work fine, because the default is on the parameter, not on the
property:

class Test {
    public function __construct(
        private Logger $logger =3D new NullLogger,
    ) {}
}

The main argument against this is that it will result in some places using
"constant expressions" being more powerful, and some being less powerful.

Regards,
Nikita

--000000000000d6635805c20ae951--