Re: Undefined variables undefined order

I don't see a big problem changing this for few opcodes in PHP-7 VM, and make behavior "more defined". On the other hand I don't think we shouldn't "define" the order of operand evaluation. This may prevent us performing optimisations in the future. Fixing this in PHP-5.* doesn't cost the effort from my point of view. Thanks. Dmitry. On Tue, Jun 9, 2015 at 4:05 PM, Matt Wilmas <php_lists@realplain.com> wrote: > Hi all, > > ----- Original Message ----- > From: "Sara Golemon" > Sent: Monday, May 11, 2015 > > On Mon, May 11, 2015 at 5:12 PM, Matt Wilmas <php_lists@realplain.com> >> wrote: >> >>> ----- Original Message ----- >>> From: "Stanislav Malyshev" <smalyshev@gmail.com> >>> Sent: Monday, May 11, 2015 >>> >>> argument. I'd like to propose making the order of evaluation defined >>>>> by splitting this into separate statements: >>>>> >>>> >>>> What is the purpose of this? I.e. why is it important that these notices >>>> would be produced in certain order? >>>> >>> >>> Logic, consistency, "polish," etc. :-) >>> >>> Exactly this. :) >> >> It's just my CDO kicking in. It's not necessary for the language to >> function. Heck, HHVM already matches PHP 5.1-7.0's out-of-order >> behavior, so fixing PHP only creates double work for me. I just look >> at these error messages and twitch uncomfortably. >> > > Hah, looks like this just changed last week after barely 3 weeks. :-P I > didn't verify, just noticed the code change: > > http://git.php.net/?p=php-src.git;a=commitdiff;h=c09698753e7d1d95299dca54c8ca888c885fd45b > > Andi hasn't objected, yet. :-O And ironically it was part of an > optimization... > > Now CONCAT is consistent, but not others. Which places need changing > anyway? Just binary ops in VM? > > A couple/few extra instructions are unavoidable, I guess on any > architecture, for the intermediate save of op1, but can anyone show that it > makes ANY measurable difference (other than instruction count)? > > For ADD, MUL, IS_[NOT_]IDENTICAL, IS_[NOT_]EQUAL, BW_*, and BOOL_XOR, ops > can be passed as > > ... result, op2, op1); > > with no ill effects (I think) and still have the same (fewest) > instructions as now! That is, if anyone thinks, or can show, that it > matters. :-) > > Whoops, didn't check first -- I see ADD, MUL, and IS_[NOT_]EQUAL (among > others) are already consistent/fixed (but extra instructions :-D). > > -Sara >> > > - Matt > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >