# Allow (...)->foo() expressions not only for `new` - Thread: https://externals.io/message/66197 - Original archive: https://news-web.php.net/php.internals/66197 - Started by Nikita Popov on 2013-02-25T16:14:27+00:00 - Messages: 32 - RFC: new MyClass()->method() without parentheses (Implemented (PHP 8.4)) — https://externals.io/rfc/new_without_parentheses.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/66197.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #66197 — Nikita Popov — 2013-02-25T16:14:27+00:00 URL: https://externals.io/message/66197#66197 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 --- ## #66199 — Jonathan Wage — 2013-02-25T16:20:01+00:00 URL: https://externals.io/message/66197#66199 · In reply to: #66197 It makes sense to me. +1 for making the syntax more consistent and natural. - Jon > 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 > -- Connect with me on *http://twitter.com/jwage* and http://about.me/jwage to keep in touch. Join OpenSky today: http://osky.co/l6a75g --- ## #66203 — Pierre Joye — 2013-02-25T17:06:17+00:00 URL: https://externals.io/message/66197#66203 · In reply to: #66197 > > Thoughts? I like the idea. I can't see nor imagine any BC breaks that could be introduce by this change. Cheers, --- ## #66204 — Sara Golemon — 2013-02-25T17:56:18+00:00 URL: https://externals.io/message/66197#66204 · In reply to: #66197 > 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. > A winner is you. --- ## #66205 — Daniel Macedo — 2013-02-25T18:03:01+00:00 URL: https://externals.io/message/66197#66205 · In reply to: #66204 Yeah, like this as well, and +1 for consistency. --- ## #66208 — Christopher Jones — 2013-02-25T18:12:54+00:00 URL: https://externals.io/message/66197#66208 · In reply to: #66197 > 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. I think a brief RFC would be good to clarify and give some more examples of what "any expression" is. Seeing more examples would help people evaluate the impact and see the use cases. It would also help the doc process. (For me, it's changes like Sara's trailing comma proposal that are too small to have needed an RFC) Chris > > Thoughts? > Nikita > -- christopher.jones@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #66213 — Pierre Joye — 2013-02-25T18:41:59+00:00 URL: https://externals.io/message/66197#66213 · In reply to: #66208 hi, On Mon, Feb 25, 2013 at 7:12 PM, Christopher Jones wrote: > I think a brief RFC would be good to clarify and give some more examples of > what "any expression" is. Seeing more examples would help people > evaluate the impact and see the use cases. It would also help the doc > process. > > (For me, it's changes like Sara's trailing comma proposal that are too > small to have needed an RFC) I think there is no small enough changes in the syntax or in the engine that would not justify a RFC. There is always (or almost always) edge cases being caught up while writing or rewieving a RFC. -- Pierre @pierrejoye --- ## #66219 — Ralph Schindler — 2013-02-25T21:41:19+00:00 URL: https://externals.io/message/66197#66219 · In reply to: #66197 > 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. I like it, we discussed this 2 years ago, could you address my original use case? Would it work: $value = ($obj = new Foo)->produceAValue(); http://news.php.net/php.internals/56684 -ralph --- ## #66220 — Sara Golemon — 2013-02-25T22:07:52+00:00 URL: https://externals.io/message/66197#66220 · In reply to: #66208 > (For me, it's changes like Sara's trailing comma proposal that are too > small to have needed an RFC) > When it comes to changing syntax, there is no such thing as too small of an RFC IMO. Runtime changes can occasionally be hand-waved, but syntax changes are serious business. -Sara --- ## #66221 — Bob Weinand — 2013-02-25T22:20:16+00:00 URL: https://externals.io/message/66197#66221 · In reply to: #66220 Am 25.2.2013 um 23:07 schrieb Sara Golemon : > > […] > When it comes to changing syntax, there is no such thing as too small > of an RFC IMO. Runtime changes can occasionally be hand-waved, but > syntax changes are serious business. > > -Sara Don't consider it as a syntax change, only as a bugfix. It must have been a bug, that this degree of conformity was not yet reached. :-P It's only stupid to vote about such microscopic changes as long as there are no real arguments against it in the discussion preceding the implementation. Bob --- ## #66222 — Lars Strojny — 2013-02-25T22:45:16+00:00 URL: https://externals.io/message/66197#66222 · In reply to: #66221 Hi Nikita, Am 25.02.2013 um 23:20 schrieb Bob Weinand : [...] > > […] I very much like it, it’s a good change. But can we have a (short) RFC nevertheless? cu, Lars --- ## #66223 — johannes@schlueters.de — 2013-02-25T22:51:35+00:00 URL: https://externals.io/message/66197#66223 · In reply to: #66221 > Don't consider it as a syntax change, only as a bugfix. It must have been a > bug, that this degree of conformity was not yet reached. :-P > > It's only stupid to vote about such microscopic changes as long as there are > no real arguments against it in the discussion preceding the implementation. This affects lots of tools: IDEs, Code Analyzers, ... It might also affect other syntax changes one might think of. Not a small thing. Please mind the few processes we have. johannes --- ## #66224 — Stas Malyshev — 2013-02-25T23:08:16+00:00 URL: https://externals.io/message/66197#66224 · In reply to: #66221 Hi! > Don't consider it as a syntax change, only as a bugfix. It must have been a > bug, that this degree of conformity was not yet reached. :-P If it changes syntax, it's by definition a syntax change. It does not matter if you think it should be changed and if you think it's a bug, it still should be properly reviewed and approved. > It's only stupid to vote about such microscopic changes as long as there are > no real arguments against it in the discussion preceding the implementation. It's not stupid to have RFC for all syntax changes. This allows us to keep track of it and gives us venue that all involved (including tool makers, etc.) can follow and be reasonably sure they didn't miss syntax change because somebody considered it microscopic. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #66225 — Jelle Zijlstra — 2013-02-25T23:08:24+00:00 URL: https://externals.io/message/66197#66225 · In reply to: #66197 2013/2/25 Nikita Popov > 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(). > > Out of curiosity, will the parser blow up if we remove the requirement for parentheses, so that things like "foo"->bar() would be possible? > 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 --- ## #66226 — Bob Weinand — 2013-02-25T23:16:33+00:00 URL: https://externals.io/message/66197#66226 · In reply to: #66224 Am 26.02.2013 um 00:08 schrieb "Stas Malyshev" : > Hi! > > > […] > > If it changes syntax, it's by definition a syntax change. It does not > matter if you think it should be changed and if you think it's a bug, it > still should be properly reviewed and approved. > > > […] > > It's not stupid to have RFC for all syntax changes. This allows us to > keep track of it and gives us venue that all involved (including tool > makers, etc.) can follow and be reasonably sure they didn't miss syntax > change because somebody considered it microscopic. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 Ok, you are right. Even if I am not a fan of this bureaucracy, I see that this is useful and nescessary. I'll appreciate this in future. Bob --- ## #66227 — Sara Golemon — 2013-02-26T00:33:07+00:00 URL: https://externals.io/message/66197#66227 · In reply to: #66222 > > […] > Seeing this quoted makes me realize I expressed myself poorly. What I meant to convey was: When it comes to syntax changes, there's no such thing as too small of a change to need an RFC. Which I think most parsed out correctly, but I want to be clear on that position. Bugfix or not, a parser change is a parser change. --- ## #66228 — Christopher Jones — 2013-02-26T00:43:38+00:00 URL: https://externals.io/message/66197#66228 · In reply to: #66227 > > […] > Seeing this quoted makes me realize I expressed myself poorly. What I > meant to convey was: > > When it comes to syntax changes, there's no such thing as too small of > a change to need an RFC. > > Which I think most parsed out correctly, but I want to be clear on > that position. Bugfix or not, a parser change is a parser change. > It is actually great to see support for the RFC process. Any new RFC page created in the wiki will get a bigger template than previously provided. It looks like: https://wiki.php.net/rfc/template. (Also see https://bugs.php.net/bug.php?id=64256 about updating the template). Whether it actually helps improve the quality of RFCs remains to be seen. Chris -- christopher.jones@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #66229 — Dmitry Stogov — 2013-02-26T06:41:59+00:00 URL: https://externals.io/message/66197#66229 · In reply to: #66197 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. > 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 --- ## #66231 — Stas Malyshev — 2013-02-26T07:43:03+00:00 URL: https://externals.io/message/66197#66231 · In reply to: #66229 Hi! > - 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 I remember now this was somewhat of a problem - when the temp is destroyed? I.e. I guess we could stick FREE_TMP at the end of the expression but then indeed it has to happen after assignment is done, and that may require longer memory than the parser currently has. I didn't look at the patch yet so not sure how it works out, will do soon. > > […] Please do not rush it. It looks simple but there might be very complex edge cases with dealing with temps and lifetimes, we need to check them thoroughly. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #66240 — Lazare Inepologlou — 2013-02-26T12:29:24+00:00 URL: https://externals.io/message/66197#66240 · In reply to: #66197 Hello Nikita, 2013/2/25 Nikita Popov > Hi internals! > > PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new > 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? > 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 > Lazare INEPOLOGLOU Ingénieur Logiciel --- ## #66241 — Sebastian Krebs — 2013-02-26T12:35:47+00:00 URL: https://externals.io/message/66197#66241 · In reply to: #66240 2013/2/26 Lazare Inepologlou > Hello Nikita, > > 2013/2/25 Nikita Popov > > > […] > 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 = 'Classname'; } else { $bar = new BarClass; } new $bar->baz(); // "(new $bar)->baz()" or "new ($bar->baz())"? > > > > > > […] > Removing > > […] > one > > […] > consider > > […] > , > > […] > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > -- github.com/KingCrunch --- ## #66242 — Alain Williams — 2013-02-26T12:58:05+00:00 URL: https://externals.io/message/66197#66242 · In reply to: #66241 > 2013/2/26 Lazare Inepologlou > > > […] > > 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 = 'Classname'; > } else { > $bar = new BarClass; > } > > new $bar->baz(); // "(new $bar)->baz()" or "new ($bar->baz())"? The precedence is quite clear, it would be the first, see: http://www.php.net/manual/en/language.operators.precedence.php However, I do agree that it might be a bit confusing. What is disappointing is that I cannot go: ($f = new Foo)->bar(); That does not suffer from a lack of clarity on intent. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include 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. > All these edge-cases are covered by not being allowed :) The old (new Foo)->bar syntax did not allow usage as a variable and I stayed with that. I.e. (expr)->xyz will still be an expression, not a variable and as such (expr)->xyz = 'foo' will be a syntax error. I stayed with the old behavior because I thought that it would just be a small bugfix-like change that way, whereas allowing usage in write-context could require larger changes (though I haven't tried, maybe its just as simple). But now that everybody seems to think that this is a major change that requires serious consideration, I guess I can have a look at the write-context use too :) Nikita --- ## #66249 — Dmitry Stogov — 2013-02-26T16:48:35+00:00 URL: https://externals.io/message/66197#66249 · In reply to: #66244 > > > > […] > > All these edge-cases are covered by not being allowed :) The old (new > Foo)->bar syntax did not allow usage as a variable and I stayed with that. > I.e. (expr)->xyz will still be an expression, not a variable and as such > (expr)->xyz = 'foo' will be a syntax error. > At least the first case (passing constant by reference) is already in PHP-5.5 and should be fixed. > I stayed with the old behavior because I thought that it would just be a > small bugfix-like change that way, whereas allowing usage in write-context > could require larger changes (though I haven't tried, maybe its just as > simple). But now that everybody seems to think that this is a major change > that requires serious consideration, I guess I can have a look at the > write-context use too :) > Yeah. It's not a simple patch. In the past, we had a lot of problems after introducing foo()[$i] syntax, because some edge cases were not taken in account. Thanks. Dmitry. --- ## #66250 — Nikita Popov — 2013-02-26T16:49:08+00:00 URL: https://externals.io/message/66197#66250 · In reply to: #66229 > 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. > I just played a bit with it and came up with the following (additional) patch to support use in write context: https://github.com/nikic/php-src/commit/31705dd8c53efe3bb52d6aae483a324e5a511ae9It throws an error if the write is done on a TMP or CONST, but things like (new foo)->bar = 'x' will work. Though I'm not quite sure whether this is really necessary, at least I don't see much use for it. Reading your mail again, I missed the second point (about destruction of temporary). But I wonder how it could cause any issue. I mean, FREE op is only inserted when expression is used as statement, which is not the case here. Or am I missing something? Nikita --- Next page: https://externals.io/message/66197.md?page=2