Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114924
MIME-Version: 1.0
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <88588b8f-5729-4458-90b1-c602f751e128@www.fastmail.com> <CAF+90c9EaGreC0y6FagwLn+2OSQUgcQe9UmQdzZaqEYGw0aJbQ@mail.gmail.com>
 <33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com> <CAF+90c_nKeFJMD8zZefCHNEhZyrp9snuKgj8VRxNhwUi8h41Bw@mail.gmail.com>
 <20210617115323.1a6c26d7@mcmic-probook.opensides.be>
In-Reply-To: <20210617115323.1a6c26d7@mcmic-probook.opensides.be>
Date: Thu, 17 Jun 2021 13:03:20 +0300
Message-ID: <CAAwdEzCRDVSL9-HVB1Dx1PorCcNpxmRo5BnJHq3cfvPGVjiz=A@mail.gmail.com>
To: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come.chilliet@fusiondirectory.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001b932c05c4f35284"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000001b932c05c4f35284
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 17, 2021 at 12:53 PM C=C3=B4me Chilliet <
come.chilliet@fusiondirectory.org> wrote:

> Le Wed, 16 Jun 2021 10:16:37 +0200,
> Nikita Popov <nikita.ppv@gmail.com> a =C3=A9crit :
>
> > 1. Eagerly evaluate initializers on declaration. This is what I tried i=
n
> 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 separa=
te
> > 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 a=
t
> > 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 w=
e
> 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?
>
> C=C3=B4me
>
> I think this message might have more details for why option 1 is not
simple to solve: https://externals.io/message/113347#113607

--0000000000001b932c05c4f35284--