Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108025 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42784 invoked from network); 7 Jan 2020 14:03:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Jan 2020 14:03:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AF31A180505 for ; Tue, 7 Jan 2020 04:08:27 -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,SPF_HELO_NONE,SPF_PASS 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-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 ; Tue, 7 Jan 2020 04:08:27 -0800 (PST) Received: by mail-lf1-f45.google.com with SMTP id m30so38682675lfp.8 for ; Tue, 07 Jan 2020 04:08:27 -0800 (PST) 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=I7tp5dG1HaQkWkgFc5XfjTOiOHme0sccQV9eWFlFVI4=; b=TPT8R3lFUunOo4PHPTVKY3hThW+5udZz8L+eH0mp9lAAdWVlw6R8LCWAGT4WRe3h4t pipUgnpz0/OOKsx9Se1D1RHc/YfH+M994FxDqqtKT3JRHOi+oeXy1tZys87kYaTCnzCH a08noE54t7zs/3HJu5TBV3vwmDVtN0ZKbPvxRQF946qZb+LAdiHE0LqeS40qCZZQE5Tr dWxIQm9kxhs1QKciPb/llR2W6OTfdZSFMlC/XCpaQPYMtVzFjVAyW+jERJPUfLASPf6w p6NAeMP4xO0DdLR3rTBwOx6PIaIckuamftVKhoS7rErOoK/txrx2xW6pBhAvrz5mYqBx z7ug== 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=I7tp5dG1HaQkWkgFc5XfjTOiOHme0sccQV9eWFlFVI4=; b=oc/vfQLyV2xyEDV6jf4/FYfnZmBk0+/33eKPZSZFXgq4IODGBPt+RQFhU4ek7mSQSX 6cK2fnP/FvwLuJ90YAPjSxXsKo2boFVZ788z/VVL09i0nKYsgrkMjchdI2EGUliOO4mT bMUSBwKR6lEc3hz1al8uO0NZXXLIR9zpmWbv6siGdofBHqQRbap+Fx3fNniP5VjW9abh 64x19fFt1JkOQDmzZYbbG4pi3L+T270/zgCI3YXsXN0GCMTNXexaA6FDudiVHPtojBtP /+ydltzDRAOdFEVbQI+6EzSHPlVH2Hixzkzq5wuaBiQNNp6hd4c1KtF0dokEPFtFB/EF qehA== X-Gm-Message-State: APjAAAU/G50U1B8wE/fXcOWuugUFAUq6gL2UgTPiHw6Nqhel6Ou1Ujz7 bfRgadT/6d/OSEMxnOYZCfXc0ompPWhTS+JI9HA= X-Google-Smtp-Source: APXvYqyrRvGJNFlilengV3MCl0chVek87tnx1WL+6nMhtjITr9CHshWzNyiKXqp5EkifRk6A7M7+fzoCL4Zb0fev40M= X-Received: by 2002:a19:5e16:: with SMTP id s22mr59717805lfb.33.1578398902654; Tue, 07 Jan 2020 04:08:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 7 Jan 2020 13:08:06 +0100 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000e81beb059b8ba1ec" Subject: Re: [PHP-DEV] [RFC] Variable syntax tweaks From: nikita.ppv@gmail.com (Nikita Popov) --000000000000e81beb059b8ba1ec Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 11:43 AM Rowan Tommins wrote: > On Tue, 7 Jan 2020 at 10:23, Nikita Popov wrote: > > > I'd like to propose a small RFC, which addresses a few minor issues that > > have not been handled by the original "uniform variable syntax" RFC: > > > > https://wiki.php.net/rfc/variable_syntax_tweaks > > > > > Hi Nikita, > > Thanks for this, I'm definitely a fan of this kind of consistency, even if > it rarely matters in practice. :) > > Regarding instanceof, and specifically your last alternative: > > > The second possibility is to relax the restrictions around the > right-hand-side of instanceof entirely. This would involve treating it as a > normal expression, and then reinterpreting plain constant accesses as class > name references instead. > > Am I right in thinking that another disadvantage of this is that you > couldn't use a bare constant to define a class name, thus introducing a new > inconsistency? That is, using a bracketed form, it should be possible to > write: > > const CLASS_NAME='MyClass'; > var_dump( $string instanceof {CLASS_NAME} ); > > or: > > const CLASS_NAME='MyClass'; > var_dump( $string instanceof (CLASS_NAME) ); > > but using the "reinterpreted expression" option, you'd need to do something > hacky to force the interpretation as a constant, like: > > const CLASS_NAME='MyClass'; > var_dump( $string instanceof ('' . CLASS_NAME) ); > If we went with this option, we'd only interpret a plain "constant" access as a class name reference. "instanceof (FOO)" should definitely be interpreted as a constant access, not a class reference. Nikita --000000000000e81beb059b8ba1ec--