Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66197
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Date: Mon, 25 Feb 2013 17:14:27 +0100
Message-ID: <CAF+90c8o=0u3deM6LA6TW9GjDeNrZA_16TAPBmHJQ7mN_P4v+A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb1f4aed66c5c04d68ed532
Subject: Allow (...)->foo() expressions not only for `new`
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8fb1f4aed66c5c04d68ed532
Content-Type: text/plain; charset=ISO-8859-1

Hi internals!

PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
Foo)->bar and (new Foo)['bar'].

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 already
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_objects,
so I can do calls like ("foo")->bar().

A nice side benefit from this is that it removes a shift/reduce conflict
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 types
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

--e89a8fb1f4aed66c5c04d68ed532--