Re: Undefined variables undefined order

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