Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108165 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 4179 invoked from network); 16 Jan 2020 11:05:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jan 2020 11:05:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A96B21804D1 for ; Thu, 16 Jan 2020 01:12:48 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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, 16 Jan 2020 01:12:48 -0800 (PST) Received: by mail-wr1-f47.google.com with SMTP id d16so18308034wre.10 for ; Thu, 16 Jan 2020 01:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XKB8g7QEb7+U/XyjfH6VdfBZfdYYCbi+d4sal7g8jnw=; b=smIpZCTIve4O4Yj2wngW8uv+ODvTFla/vW2WtMmcqGma3SEYVtGTCCHjOalx2dNzry 6VqdcRQN3QxmYkZI5eU3QpfDffWd7kW+RMcdTSIfroEw9fB5vCAjDgyWONElYlVhRQrg yw2mr8uJsoC9C12rjjBSlq2t7tZDkFaxv6ZG4z0WGoNW9HL2uyWgcpNWGVcqkAutIbKo Alkp6qI2k6iVjeZmvfhM58vHY08IB9u0y56+YkX5yryrtxRomOBjl2vgbeREZNsi3xDm yuHsFPy+3+YlvWcsw0Tv4cKgAmM42m/6snAWLpsqXBEIdYiegNsr29IT01+4AbI2Yztp Mpjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XKB8g7QEb7+U/XyjfH6VdfBZfdYYCbi+d4sal7g8jnw=; b=VDPGpk3mq+dcQQSk/Z6v5Gt9DHaT/jZDssfygCdEB/lZ/C82P+Zf15lCMpUkaetOE2 nivvIFZf+6yQRowoh397Ww/R89Sf79a2TGSxiAr2plmypRHN2wlu8YDayjiuyW0vnSZI Vfu3Yp+WgqxUHnYmXjodZIw3yIzQ944iaD7Wy9/SyV4t/OL+0+9izcB+WJPlt1F6UWGT frU75qW+1ehqzxUQcqolWuF95XS/lJEHms6AxuMv3mF4/b++A6FmFNq4YQpc0yxKwJn5 4WS8k7xj6IZiDUQSeoHvDeGLzfS7g3i0m8UToTMpIYfx+/bY/Q6cRyEHnbJCN3C6V7qq SXmg== X-Gm-Message-State: APjAAAWRkUfYJ5GpeTa0mpSwe1I5o03VDk+9hNxXMFTlsrX6ptV3N0wL LKtKH64aR5u+UfGFoyhSccI= X-Google-Smtp-Source: APXvYqykFIPyGUYi6JpI4GRqLYVDKbvp9qqo4VkuDAVukM1FOFfvQDQ1qiuNYhh6djOm6y3Yg7Hyiw== X-Received: by 2002:a5d:6708:: with SMTP id o8mr2170028wru.296.1579165963929; Thu, 16 Jan 2020 01:12:43 -0800 (PST) Received: from [192.168.0.63] (84-75-30-51.dclient.hispeed.ch. [84.75.30.51]) by smtp.gmail.com with ESMTPSA id u7sm3660797wmj.3.2020.01.16.01.12.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 01:12:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) In-Reply-To: Date: Thu, 16 Jan 2020 10:12:41 +0100 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <629789F9-8E61-43DB-B186-75779A8372E7@gmail.com> References: To: Nikita Popov X-Mailer: Apple Mail (2.3608.40.2.2.4) Subject: Re: [PHP-DEV] [RFC] Variable syntax tweaks From: claude.pache@gmail.com (Claude Pache) > Le 7 janv. 2020 =C3=A0 11:23, Nikita Popov a = =C3=A9crit : >=20 > Hi internals, >=20 > 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: >=20 > https://wiki.php.net/rfc/variable_syntax_tweaks >=20 > This is all about edge cases of edge cases, of course. I think the = only > part here that is not entirely straightforward and may need some = discussion > is how arbitrary expression support for instanceof should be handled. >=20 > Regards, > Nikita Hi, The RFC looks good for me, except for one point. Concerning the = arbitrary expression support for `new` and `instanceof`, I strongly = think that the most consistant choice for delimiters among =E2=80=9C(...)=E2= =80=9D (parentheses) and =E2=80=9C{...}=E2=80=9D (braces) is not braces = =E2=80=9C{...}=E2=80=9D, but parentheses =E2=80=9C(...)=E2=80=9D. Your = argument is based on the position of the expression (RHS vs LHS). My = argument is based on the type (in a broad sense) of the thing that the = expression is supposed to represent. The braces are used when the expression is expected to represent: * a variable name: `${...}` * a property name: `$x->{...}` =E2=80=94 `X::${...}` * a method name: `$x->{...}()` =E2=80=94 `X::{...}()` In all those cases, the expression inside `{...}` must evaluate to a = string, and will be interpreted as a name. On the other hand, the parentheses are used when the expression is = expected to represent: * an array: `(...)["key"]` * an object: `(...)->prop` =E2=80=94 `(....)->meth()` =E2=80=94 `clone = (...)` * a function: `(...)($arg)` * a class: `(...)::KONST` =E2=80=94 `(...)::${statProp}` =E2=80=94 = `(...)::${statMeth}()` In the first two cases, the expected entity, =E2=80=9Carray=E2=80=9D or = =E2=80=9Cobject=E2=80=9D, is a first-class value, and the expression = inside `(...)` will be interpreted as such. The last two cases are more interesting. For the =E2=80=9Dfunction=E2=80=9D= cases, it can be: * a string representing a function (interpreted as the fully qualified = name of a function); * an array `[ $obj, "meth" ]`, `[ "klass", "meth" ]` or a string = "klass::meth" representing a method; * a closure or another object implementing the magic __invoke() method. For the =E2=80=9Cclass=E2=80=9D case, it can be: * a string representing a class (interpreted as the fully qualified name = of a class); * an instance of a class. In those cases, the expected entity may be a first-class citizen (a = closure, an instance of a class), or an entity that, although not a = first-class citizen, is unambiguously(*) represented by some other = first-class value (a function by their fully qualified name, etc.) and = could have been reasonably designed as first-class citizen (and indeed, = a function may be replaced with a Closure object with the same = functionality). (*) (For the sake of not complicating the argument, I=E2=80=99m ignoring = callables whose meaning depends on context such as `["self", "foo"]`.) You rightly noted that the braces `{...}` are used exclusively on the = RHS; that follows from their meaning: a bare name has no significance = out of context, where the context is whether it is a function name, or = whether it is a property/method name and of which object/class the = property/method is, or etc. That context is more naturally provided = before (at the left of) the name. On the other hand the parentheses `(...)` are often used on the LHS: = this place is the natural place for an entity (an object, a class, etc.) = that don=E2=80=99t need more context to be well-defined, and that serves = as target for some action (call the function, look up the property of an = object, etc.) However, although the entity is often placed at LHS, = this is not systematic; consider f.e. `clone $obj`, which is quite = similar to `new klass`. =E2=80=94Claude