Nikita,
You're completely right about the expanded expressions, but I'm not sure
its an edge-case per-se.
The problem with the current syntax is that the resultant of the 'new'
operation is lost UNLESS your chained method returns $this - which IMO
makes it about as 1/2 as useful as it really could be.
In the case of "new" though, the resultant is always an object, it seems
like it should be permissible to change the parser to allow for variable
assignment of the target object.
I think for people just trying out this new behavior (by seeing it in
the release notes as (new Foo)->bar()), the next logical thing is to try
this syntax:
($foo = new Foo)->bar()
// OR in bison
'(' variable '=' new_expr ')'
I did it, and I see other people doing it too. So I guess the question
is... "how edge case is this edge case?" :)
Unfortunately, this new feature was not in any preview release, it was
only in a release candidate.
-ralph
On 11/30/11 12:51 PM, Nikita Popov wrote:
Hi Ralph!
This (in it's current form) doesn't look like a good idea to me. You
are only handling yet another edge case. ($foo = $bar = new A)->bar()
would again not work.
If we really want this kind of (expr)-> syntax, then it should really
accept *any* expr. But I am not quite sure whether this will work out
easily because in this case we can't be sue that expr is an object
(but maybe it'll be simple, I just don't know).
Nikita
On Wed, Nov 30, 2011 at 7:09 PM, Ralph Schindler
<ra...@ralphschindler.com> wrote:
Hey all (Filipe),
This was brought up in the thread "New dereferencing syntaxes in 5.4".
I too think this would be beneficial:
$value = ($obj = new Foo)->produceAValue();
but the current parser (branch 5.4) doesn't have a rule for this. I've
attached a quick/working patch, but I don't fully understand the
ramifications of such a patch.
Can someone explain the drawbacks of increasing the "%expect n" for me?
Would this many s/r require/benefit from a new expression grouping?
More to the point, can we have this small change for 5.4?
Thanks in advance.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
