Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108179
MIME-Version: 1.0
References: <CAF+90c-9ACg_v=B94Ok1tM5-xE9kO4sGQ3eL_j_qjaMWNK+QHw@mail.gmail.com>
 <629789F9-8E61-43DB-B186-75779A8372E7@gmail.com>
In-Reply-To: <629789F9-8E61-43DB-B186-75779A8372E7@gmail.com>
Date: Fri, 17 Jan 2020 14:20:58 +0100
Message-ID: <CAF+90c_iFnCj=3aNhA9HxUqTPk0UJoPO8s+R+_kV-buCxZg4Vw@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f86a37059c55d0eb"
Subject: Re: [PHP-DEV] [RFC] Variable syntax tweaks
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f86a37059c55d0eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 16, 2020 at 10:12 AM Claude Pache <claude.pache@gmail.com>
wrote:

>
>
> > Le 7 janv. 2020 =C3=A0 11:23, Nikita Popov <nikita.ppv@gmail.com> a =C3=
=A9crit :
> >
> > Hi internals,
> >
> > I'd like to propose a small RFC, which addresses a few minor issues tha=
t
> > have not been handled by the original "uniform variable syntax" RFC:
> >
> > https://wiki.php.net/rfc/variable_syntax_tweaks
> >
> > 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.
> >
> > 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 (pare=
ntheses) 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 functionalit=
y).
>
> (*) (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 i=
t
> is a property/method name and of which object/class the property/method i=
s,
> or etc. That context is more naturally provided before (at the left of) t=
he
> 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 ta=
rget 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`.
>

Thanks for the feedback Claude.

I think you make a compelling case, and have updated the RFC to use "new
(expr)" and "$x instanceof (expr)" syntax instead.

Regards,
Nikita

--000000000000f86a37059c55d0eb--