Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113607 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 57208 invoked from network); 19 Mar 2021 12:03:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Mar 2021 12:03:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6EB651804D1 for ; Fri, 19 Mar 2021 04:57:47 -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-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 ; Fri, 19 Mar 2021 04:57:46 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id 184so11595420ljf.9 for ; Fri, 19 Mar 2021 04:57:46 -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=6zwSvob8V94X8fJs9bigq1FL+nU6P+a1FYhcrp4BEEA=; b=RBdF48FGaSnXhjSP4CqyVa3S7P6zLtZIO8CqopMFiqEHWtjZsUUp0aIowkbEsgYQbt dCKAq48yKJLvH4xn2hLrpEgQeEbHea9TufgDpz47x9dPjlcv5ADM0etYR8Ff/97dD6rS rwPVvhqx8006pSOiNXdWAenrlYZpo8DpU7AZlPc+Cjx4YVbWgvow9eSh/LKvGSLU3Ceg 5kpYzwybAoQ/IB1ROCFWQbbLcIMAlHdApFIsmyOR6XdScmXzYk3RscrAU7R8v1lLN/ud k/QsODQfWgon6TsagX+HVIyyU+I+0yNi/Ra+QIIEBlvIw74WdhQhHeUWWZH30UnvRzM2 6bgw== 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=6zwSvob8V94X8fJs9bigq1FL+nU6P+a1FYhcrp4BEEA=; b=oUj7Si8hybgAl9eyS5+0c9gF3gwchvxKa1XBRA1MUSBvZA6HJnMZrY6xVnp8x45xkv nEWB7jJgfqdtLkD2p8T2Motmd6AWNuFQBKwSsHspYj+L63epWs6K3jixrocJ6iCZVTCr JOBsv9qVpe6WhH7QprF9d5XiixYqlueuthEULtcBASwmbTv6ChZCWpYjobDdbJmFnjcy iotpzKqVKh6ND2twFOsWTMuHLAgvJ2BRsw49iWPTPipLxhOoLv/NQSdTf1z/5pATizG4 G3DXScxc74SA0ohbOwO/n1s203S3EruXFV7wfoDuREpKbM5qmQzsSiOGDbF/Kz5yICfE uYYQ== X-Gm-Message-State: AOAM531dbf00lRa2ftZZ38QQlPZpSJdLp3eBlQUQytQLp/p7RSgB+6+w LWcIIR0tFC0X/w+BXrHlGvoAFsG5RdVnK23xO0g= X-Google-Smtp-Source: ABdhPJyYp42xT6pTOHSTHySxztp86qdxWArSJjECW2Q0KjCDKSr0vSHvqoih0uO5OovDkuEr/vu8DVKgrLn6UmAsmzU= X-Received: by 2002:a2e:978b:: with SMTP id y11mr684940lji.452.1616155064491; Fri, 19 Mar 2021 04:57:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 19 Mar 2021 12:57:28 +0100 Message-ID: To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000085632605bde26c91" Subject: Re: [PHP-DEV] [RFC] New in initializers From: nikita.ppv@gmail.com (Nikita Popov) --00000000000085632605bde26c91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 19, 2021 at 12:22 PM Nikita Popov wrote: > On Wed, Mar 3, 2021 at 7:04 PM Alexandru P=C4=83tr=C4=83nescu > wrote: > >> >> On Wed, Mar 3, 2021 at 5:49 PM Nikita Popov wrote= : >> >>> On Wed, Mar 3, 2021 at 4:28 PM Alexandru P=C4=83tr=C4=83nescu >>> wrote: >>> >>>> Hi, >>>> >>>> This looks very nice and I'm interested in further steps where not onl= y >>>> 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 five >>> 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 after 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 stati= c >>> properties. Currently, PHP evaluates these semi-lazily. All class const= ants >>> and static properties are evaluated at the same time, on first "use" of= the >>> class. I would consider this to be something of an implementation detai= l. >>> 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 b= e >>> evaluated eagerly, i.e. directly after the class has been declared. Thi= s >>> would be a (minor) backwards-compatibility break, because invalid >>> constant/property declarations would error out immediately, even if the= y >>> don't get used. However, I do think that this would be the most predict= able >>> behavior once potentially side-effecting expressions are involved (we >>> already support side-effecting expressions right now, but less explicit= ly). >>> >>> >> Yes, this is what I was thinking about, to have a clear stated order of >> initialization. >> Yes, I agree that class constants and static properties should be eagerl= y >> declared when class is declared. >> >> So the order would be: >> - constants and static variables, when reaching the statement that does >> the declaration >> - class constants and static property, when class is declared, in order >> 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 declared >> 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 shoul= d > 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 / stat= ic > property initializers needs to actually be available at the time the clas= s > 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 they will be used in this particular request or not. Also opens up the question 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 than it solves, and we should go back to the previous lazy evaluation approach. Ultimately, my view here is that side-effecting constructors are a terrible idea, and if you use them then you should also carefully manage those side-effects yourself. Regards, Nikita --00000000000085632605bde26c91--