Re: Re: [RFC] [PHP 6] Uniform Variable Syntax
| From: | Rowan Lewis | Date: | Wed, 02 Jul 2014 17:58:44 +0000 |
| Subject: | Re: Re: [RFC] [PHP 6] Uniform Variable Syntax | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75171@lists.php.net to get a copy of this message | ||
How would you create a new callable object and then invoke it? Since
'nested' () is now supported:
new MagicInvoke()();
Could be the same as:
(new MagicInvoke())();
On Wed, Jul 2, 2014 at 7:25 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Wed, Jul 2, 2014 at 6:04 PM, Lazare Inepologlou <linepogl@gmail.com>
> wrote:
>
> >
> > 2014-07-02 17:51 GMT+02:00 Nikita Popov <nikita.ppv@gmail.com>:
> >
> > On Mon, Jun 9, 2014 at 3:33 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >>
> >> > Hi internals!
> >> >
> >> > I have created a proposal for a more consistent and complete variable
> >> > syntax for PHP 6:
> >> >
> >> >
> >> > https://wiki.php.net/rfc/uniform_variable_syntax
> >> >
> >> > The RFC is targeted at PHP 6 because it breaks compatibility for some
> >> > rarely used variable-variable constructs.
> >> >
> >>
> >> Any more feedback on this? Otherwise I'll start the vote sometime soon
> :)
> >>
> >>
> > Yes, in the RFC, you mention that this will be possible:
> >
> > ($obj->closure)()
> >
> > While this is very welcome, I was wandering if we could skip the extra
> > parenthesis, like this:
> >
> > $obj->closure()
> >
>
> We could skip the extra parenthesis, but that would require changing the
> meaning of method calls. This discussion turns up every now and then, one
> of the more recent ones being
> http://markmail.org/message/3zi53txadno6xrqa
> .
> A key problem was always that supporting this would break BC. However that
> BC break may be acceptable for PHP 6, so the it might be worthwhile to
> reconsider the previous decisions regarding this issue.
>
> However this is not related to variable syntax (it is a question of method
> lookup semantics), so I would suggest opening a new discussion thread for
> this (and/or write an RFC for it).
>
>
> > Likewise, this would also be nice:
> >
> > new ClassName->foo()
> >
>
> This is problematic because the following would be ambiguous:
>
> new $className->foo()
> // could be (_current_ behavior)
> new ($className->foo)()
> // or
> (new $className)->foo()
>
> Of course we could resolve the ambiguity (towards the _latter_
> interpretation) or special-case the plain-classname case. Both options do
> not seem very appealing to me. Imho it's better to keep the explicit
> syntax.
>
> Nikita
>