Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119098 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10812 invoked from network); 8 Dec 2022 13:24:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Dec 2022 13:24:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 879C9180544 for ; Thu, 8 Dec 2022 05:24:49 -0800 (PST) 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, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 8 Dec 2022 05:24:49 -0800 (PST) Received: by mail-wr1-f53.google.com with SMTP id bx10so1640172wrb.0 for ; Thu, 08 Dec 2022 05:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QUmjt1c/5KKPnyXVFsmHsILwDvnejYWkTeAlkWhE52w=; b=YIX2UuHAsTn81wWdMg7RQsIw2bomC6PGOfHJ1DBMAQ6SWF509Xwtah8laKiK8qrBL5 SqgKNk890tzUfeHfKzbX7KN4s9C8ceGT5Iok/q+pRHgmhDntd30uTyY8aIATRRMCNTJS ngtFrNXbdSglSmuq0kd+EXTycR1d6ad0bZEPz1So1jJzMjHyFbwXNbJXq+vQtaTFh3YU 2Ib6IFTzqDk5lKJex8TIs4zERcGwHdSsdcR0oxs8VfZ/e2rYGwL1+brBvUoqZrFZxef8 0H8r0XnW3RrtsOQbENm2d6vYkKeHmUTGWWQ8V51FmnSeZ8LhKbTZ2SnbrAkxvVmKBSd1 uepQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QUmjt1c/5KKPnyXVFsmHsILwDvnejYWkTeAlkWhE52w=; b=gMbFtcY10qfeAaie0+UyvFIJjTUAR160NU+Zr8Q+3prawFKQaPedUflEFsBwFf9KPp 4L/Ogrcu7gnDyyJgPLR+prQiTZxyyWueKoWbDXJ5gwLfqL0VLe1MJiqA7MhUmObJhgH1 U1DImm0+ULps+/HUTW/FOit9m295sEifiz04kGkpbutXteUXOpN/vGaTieIGn8GYqgar jdr6tUltlcFAzuvBrQhlDq+dv4jyu3vCOWP2ayaP/tP3bmHRgDsI3U2VWk5cObk6BtEr iK0zZuwwVdLivS70Qcd6gXhA2FjBOW2eVohw3O9nJz6iQ+5R8qQXOvjebw+xv5TiTZh2 p0Jw== X-Gm-Message-State: ANoB5pnwjMULJRL3nfowiXhtJBsP3TyUFwLV3K5vO062bdMDWWL4mrdv V63RTPxkuf06CyuSArvl8lnMfuZ3B//6rtO5h5p88spTXuo= X-Google-Smtp-Source: AA0mqf6uRFDXSyyoN2glM0uitg3EYivEx4bs7HD0N/rjijLA+SHsuhkskNml/JGkb0dBI0HV4NG+MyIDIchStRQ50UM= X-Received: by 2002:a5d:6ac7:0:b0:242:6284:1571 with SMTP id u7-20020a5d6ac7000000b0024262841571mr9539687wrw.709.1670505887589; Thu, 08 Dec 2022 05:24:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 8 Dec 2022 14:24:36 +0100 Message-ID: To: Ilija Tovilo Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000000669a205ef50f61a" Subject: Re: [PHP-DEV] Re: [RFC][Dynamic class constant fetch] From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --0000000000000669a205ef50f61a Content-Type: text/plain; charset="UTF-8" Hi Ilija, > I'd like to propose a simple RFC to introduce looking up class > > constants by name. We have dedicated syntax for basically all other > > language constructs. This RFC aims to get rid of this seemingly > > arbitrary limitation. > > > > https://wiki.php.net/rfc/dynamic_class_constant_fetch > > Heads up: There hasn't been much discussion on this RFC in the last > couple of weeks, thus I'd like to start the voting phase in the next > couple of days. > Thanks for the reminder about this topic. I'm wondering about this: > This RFC proposes no change in the interaction between class constant fetches and the null-coalescing operator ??. That is, Foo::{$bar} ?? null; will throw an Error if the given constant does not exist. It would be possible to suppress this error as is done for other types of member accesses. However, it's not clear whether this is desirable, especially for explicit class constant fetches. This change can be made in the future with no backwards compatibility break. Since an argument in favor of the RFC is to replace a function call by native syntax, wouldn't it be desired to allow the same for checking the existence of a const? I'm thinking about defined(), which the ?? operator would nicely replace IMHO. Are there technical reasons to not do it in this RFC? If not, could this be considered? Thanks, Nicolas --0000000000000669a205ef50f61a--