Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114925 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38462 invoked from network); 17 Jun 2021 09:52:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Jun 2021 09:52:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 04018180502 for ; Thu, 17 Jun 2021 03:09:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 17 Jun 2021 03:09:01 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id s22so8166666ljg.5 for ; Thu, 17 Jun 2021 03:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a2A5dxPvXhWHBlzcP7BmT7dopllW45phsobs8onKoR0=; b=B9Bahvkh6Cb43MAguIrNwSLcU+j9zKEORDB9r+r+PjD//OAeq7fGdA+8nq/5WIWTO0 FV7MDPW2eA336NHo72S2VbJbuLFyObjp2rRMjtqg0nviEuxPGRl2X9Mff8bospBCB2ac om/4fn/61msGhQx95plvq6vt/X/74dgZgzBCQnwcn1a0TmL7xDg9Hp9rQv6q2DpQDIAN 5Z8S1UfZ7GVm9PVjWRqevcQ8S8QxX3/0DUC+5PT3+peIJLFRWzdiWW0tyWFJ7GNDsUgG bWo+lXoeYfh3qf3f2/lnFJnQLxxKPoSqI7nvr9YGE7SkmKW8bogAFQIKo+gHpNAxVZix xP0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a2A5dxPvXhWHBlzcP7BmT7dopllW45phsobs8onKoR0=; b=QdRKEJSPYMJDbCVcXh1GSVfW6cAfwlb38WvwV0/yD797EizeKGf84DHixKNSO/3onO HbKBkiVUgX6tGoNRv+QssmJDGWxfw6193tsjCL/pjzgEf82u0Yq9D3Ee2FmMcKFg5gA4 Y3RibIEOqdnndMv5AQ5C5XDPFG4Pq/kG1pO5dGk0Nt7uIx2hrIblp/4Tv9B9eXSiBcpK cA4HfIS4IvC2Y25qUSOYhHdAg5gKZVXLcGtYNKl2Rxqg3yvG2CGprtFAop5ShkiHtX36 I1ipxF6qOcj1xSVk2E06kHLDpg6Qr+CEJS8ijIwJRFDBE+C+oZILpXcTkeh5gfaJYgOB aihA== X-Gm-Message-State: AOAM533tPfOpGcMRnIOVZXmN+GLmvraiBXvWRZ+odY9owHMRTM/Wf9/i /uHpaKmUwO/RUqrWoCmRjx8t+IwTvG1tFMnDY1I= X-Google-Smtp-Source: ABdhPJyynRSotSOD5AeerOfW511XVVxXbVgxxk3qMtg2GWTvOAUufgqWOr2lOQRO5SqiqlRkU6BEuliI9KjiWiB33fc= X-Received: by 2002:a2e:a234:: with SMTP id i20mr4054685ljm.272.1623924538468; Thu, 17 Jun 2021 03:08:58 -0700 (PDT) MIME-Version: 1.0 References: <88588b8f-5729-4458-90b1-c602f751e128@www.fastmail.com> <33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com> <20210617115323.1a6c26d7@mcmic-probook.opensides.be> In-Reply-To: <20210617115323.1a6c26d7@mcmic-probook.opensides.be> Date: Thu, 17 Jun 2021 12:08:42 +0200 Message-ID: To: =?UTF-8?Q?C=C3=B4me_Chilliet?= Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000041ed4505c4f365e4" Subject: Re: [PHP-DEV] [RFC] New in initializers From: nikita.ppv@gmail.com (Nikita Popov) --00000000000041ed4505c4f365e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 17, 2021 at 11:53 AM C=C3=B4me Chilliet < come.chilliet@fusiondirectory.org> wrote: > Le Wed, 16 Jun 2021 10:16:37 +0200, > Nikita Popov 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? > 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 --00000000000041ed4505c4f365e4--