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
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 http://twitter.com/jwage
and http://about.me/jwage to keep in touch.
Join OpenSky today: http://osky.co/l6a75g
Thoughts?
I like the idea. I can't see nor imagine any BC breaks that could be
introduce by this change.
Cheers,
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.
Yeah, like this as well, and +1 for consistency.
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
hi,
On Mon, Feb 25, 2013 at 7:12 PM, Christopher Jones
christopher.jones@oracle.com 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
(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
Am 25.2.2013 um 23:07 schrieb Sara Golemon pollita@php.net:
(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
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
Hi Nikita,
Am 25.02.2013 um 23:20 schrieb Bob Weinand bobwei9@hotmail.com:
[...]
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.
I very much like it, it’s a good change. But can we have a (short) RFC nevertheless?
cu,
Lars
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.
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.
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.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
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. :-PIt'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
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
Am 26.02.2013 um 00:08 schrieb "Stas Malyshev" smalyshev@sugarcrm.com:
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. :-PIf 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
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
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
2013/2/25 Nikita Popov nikita.ppv@gmail.com
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
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
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.
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.
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
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 assignmentAll 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
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 assignmentAll 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.
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.
Hi,
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.
From what I remember, the same problem that I spotted by foo()[$i] is
the one that we already had with foo()->prop. So it actually was a bug
fix.
--
Regards,
Felipe Pena
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 assignmentAll 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
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 assignmentAll 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,
I like this patch more (it doesn't complicate executor).
However it doesn't handle BP_VAR_FUNC_ARG, where decision about read/write
context must be done at run-time.
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.
no sense, but it may call __set() magic method, that may print something,
clobber something, throw exception, etc...
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?
Actually, I think IS_TMP operands shouldn't make any problems, but I can't
be completely sure.
Thanks. Dmitry.
On Tue, Feb 26, 2013 at 8:49 PM, Nikita Popov nikita.ppv@gmail.comwrote:
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 assignmentAll 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,I like this patch more (it doesn't complicate executor).
This patch is on top of the other one, so the executor changes still apply.
This one is only about write-context, but the executor optype changes were
necessary for read-context (as in read-context CONST/TMP are valid, unlike
in write context).
However it doesn't handle BP_VAR_FUNC_ARG, where decision about read/write
context must be done at run-time.
Good catch, I didn't consider that one (didn't even know it exists ^^).
This would require a few more changes:
https://github.com/nikic/php-src/commit/6f5483f006794dc78f8c341b1a6d7ad18c2e56be
Nikita
Hi
- 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
I've run a bunch of examples like above, with debug enabled, and so far
I could find no scenario where it would leak or access destructed
variable. So looks like it works, at least I wasn't able to find any
case where it does not :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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(), (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
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(), (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?
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())"?
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?
NikitaLazare INEPOLOGLOU
Ingénieur Logiciel
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(), (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?It could mean "new (Foo->bar())", which in this case is invalid, but there
are other cases, where this problem is more obviousif ($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 <std_disclaimer.h
Thoughts?
There is now more than enough materials to put in a well written RFC. Thanks :-)
Pierre
@pierrejoye
The idea from the user perspective is very simple and clear.
I really don't see what to discuss. All the questions are about
implementation and they must be solvable.
Thanks. Dmitry.
On Mon, Feb 25, 2013 at 5:14 PM, Nikita Popov nikita.ppv@gmail.com
wrote:Thoughts?
There is now more than enough materials to put in a well written RFC.
Thanks :-)Pierreim
@pierrejoye
hi,
The idea from the user perspective is very simple and clear.
I really don't see what to discuss. All the questions are about
implementation and they must be solvable.
The idea is all the edge cases and possible issues listed so it can be
easily reviewed and documented. As in: there is not much to discuss
but to test, document and maybe fix.
Cheers,
Pierre
@pierrejoye