On Thu, Jan 16, 2020 at 10:12 AM Claude Pache <claude.pache@gmail.com>
wrote:
>
>
> > Le 7 janv. 2020 à 11:23, Nikita Popov <nikita.ppv@gmail.com> a écrit :
> >
> > Hi internals,
> >
> > 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
> >
> > 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 “(...)” (parentheses) and
> “{...}” (braces) is not braces “{...}”, but parentheses “(...)”. 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->{...}` — `X::${...}`
> * a method name: `$x->{...}()` — `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` — `(....)->meth()` — `clone (...)`
> * a function: `(...)($arg)`
> * a class: `(...)::KONST` — `(...)::${statProp}` — `(...)::${statMeth}()`
>
> In the first two cases, the expected entity, “array” or “object”, is a
> first-class value, and the expression inside `(...)` will be interpreted as
> such.
>
> The last two cases are more interesting. For the ”function” 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 “class” 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’m 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’t 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`.
>
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
