Hi Nikita, I like the idea. But note, that it may cause some unexpected behaviour and bugs. I didn't test the patch I just guess it on my previous experience introducing similar features.
- usage expression in write context (e.g. passing constant by reference) function foo(&$foo) {} foo("abc"[0]); - destruction of temporary result ($a . $b)[4]; // if ($a.$b) is destroyed? - in some cases destruction of temporary result may cause destruction of final result ((object)(array("a"=>"b")))->a = "c"; // temporary object may be destroyed before assignment All these edge cases must be carefully analyzed. I like the current patch, and in case the edge cases won't require many hacks, I'm all for it. Thanks. Dmitry. On Mon, Feb 25, 2013 at 8:14 PM, Nikita Popov <nikita....@gmail.com> wrote: > 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 >