Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMyk_AYRKuZC79KFq61XXD3vcj2UmWdffC9Ba1LVYoGwsO96_A@mail.gmail.com>
References: <CAF+90c8o=0u3deM6LA6TW9GjDeNrZA_16TAPBmHJQ7mN_P4v+A@mail.gmail.com>
 <CAMyk_AYRKuZC79KFq61XXD3vcj2UmWdffC9Ba1LVYoGwsO96_A@mail.gmail.com>
Date: Tue, 26 Feb 2013 13:35:47 +0100
Message-ID: <CALtuQzCZxYSPQD4MxREzDxa0LHKw+xM4O9mi1yS4GErpy1fJ-w@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044287f2e66c3b04d69fe673
Subject: Re: [PHP-DEV] Allow (...)->foo() expressions not only for `new`
From: krebs.seb@gmail.com (Sebastian Krebs)

--f46d044287f2e66c3b04d69fe673
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2013/2/26 Lazare Inepologlou <linepogl@gmail.com>

> Hello Nikita,
>
> 2013/2/25 Nikita Popov <nikita.ppv@gmail.com>
>
> > Hi internals!
> >
> > PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (ne=
w
> > Foo)->bar and (new Foo)['bar'].
> >
> >
> I guess it must have been discussed, but Is there any technical reason or
> conflict that prevents us from having something like new Foo->bar(),
> without the extra parenthesis?
>

It could mean "new (Foo->bar())", which in this case is invalid, but there
are other cases, where this problem is more obvious

if ($foo) {
  $bar =3D 'Classname';
} else {
  $bar =3D new BarClass;
}

new $bar->baz(); // "(new $bar)->baz()" or "new ($bar->baz())"?



>
>
>
>
> > I'd like to extend this support to any expression instead of just new.
> >
> > Why should be do this? Because it's just an arbitrary restriction.
> Removing
> > it would for example allow clone calls in the parens, so you could do
> > something like (clone $date)->modify('...'). Which - you may have alrea=
dy
> > noticed this - is more or less a replacement for the DateTimeImmutable
> > class that was added for 5.5 (with the nice benefit of being fully
> > compatible and not being an object oriented abomination :) That's just
> one
> > example, but I think there are a lot more (especially if you also
> consider
> > that it allows array dereferencing too). One further use that is of
> > interest to me personally is for https://github.com/nikic/scalar_object=
s
> ,
> > so I can do calls like ("foo")->bar().
> >
> > A nice side benefit from this is that it removes a shift/reduce conflic=
t
> > from the parser.
> >
> > The patch for the change can be found here:
> > https://github.com/php/php-src/pull/291/files. It's a very simple patch=
,
> > it
> > basically just changes one parser rule and adjusts the allowed opp type=
s
> > for some opcodes. The rest is just the vm regeneration for the new op
> > types.
> >
> > I hope that this change is trivial enough to not require dragging it
> > through the whole RFC process. If there are no objections I'd commit it
> > sometime soon.
> >
> > Thoughts?
> > Nikita
> >
>
>
> Lazare INEPOLOGLOU
> Ing=E9nieur Logiciel
>



--=20
github.com/KingCrunch

--f46d044287f2e66c3b04d69fe673--