Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:114990 php.internals:114991 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 54522 invoked from network); 21 Jun 2021 20:32:46 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 21 Jun 2021 20:32:46 -0000 To: internals@lists.php.net,Nikita Popov Cc: PHP internals , =?UTF-8?Q?C=c3=b4me_Chilliet?= References: <88588b8f-5729-4458-90b1-c602f751e128@www.fastmail.com> <33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com> <20210617115323.1a6c26d7@mcmic-probook.opensides.be> Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= Message-ID: Date: Mon, 21 Jun 2021 22:50:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Posted-By: 213.64.245.126 Subject: Re: [PHP-DEV] [RFC] New in initializers From: internals@lists.php.net ("Björn Larsson via internals") Den 2021-06-17 kl. 12:08, skrev Nikita Popov: > 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 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? >> > > See the example in https://externals.io/message/113347#113642. 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 it in 8.2 with static property and class constant initializers or do we include it already in 8.1? Regards //Björn L