Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119017
MIME-Version: 1.0
References: <CAPyj-LDUD7PZ9Bcpmsc0B_WjdnOSBPhdwfJsseB6n8PesPbzhw@mail.gmail.com>
 <CAF+90c8kcvP9KE-0nhs7Ax1P4Za-ST8ikQysfM7_Xw-C8Ufvhw@mail.gmail.com>
In-Reply-To: <CAF+90c8kcvP9KE-0nhs7Ax1P4Za-ST8ikQysfM7_Xw-C8Ufvhw@mail.gmail.com>
Date: Thu, 17 Nov 2022 21:21:02 +0100
Message-ID: <CAPyj-LByEm0rmEqmuadK=aAa3HUZ3_gH-F65iiekqYrQzFHiCw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi everyone

Sorry for the late reply.

I won't waste too many lines on usefulness as it is highly subjective.
The change will seem worth it to some people and not to others. IMO
language consistency is important and mainly what I'm striving for.

---

Hi Micha=C5=82

> Can it be extended to non class constants and additionally deprecations p=
lan for constant() function?

I'm not sure what that syntax would look like. {$foo} is not a viable
option since it is ambiguous or rather would require arbitrary
lookahead (i.e. {$foo;} is valid syntax today). A different syntax
would be possible but inconsistent with the existing options. In any
case, this would likely require its own RFC and should be discussed
separately.

---

Hi Nikita

> See https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-a=
nd-memory-safety for why the order of execution is the way it is. As class =
constants do not support writes, these concerns do not apply, and the "norm=
al" order can be used (as you propose).

Thank you! I remembered discussing this back when implementing the
nullsafe operator but was fuzzy on the details :) This makes more
sense to me now. I tried to clarify in the RFC.

Ilija