On 6 December 2014 22:25:50 GMT, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >Hi Rowan, > >On Sat, Dec 6, 2014 at 11:25 PM, Rowan Collins ><rowan.coll...@gmail.com> >wrote: > >> On 06/12/2014 03:03, Yasuo Ohgaki wrote: >> >>> Hi Rowan, >>> >>> On Fri, Dec 5, 2014 at 6:12 PM, Rowan Collins ><rowan.coll...@gmail.com >>> <mailto:rowan.coll...@gmail.com>> wrote: >>> >>> The author of function f1() presumably designed it to apply some >>> change to $v, rather than executing only for its side effects >and >>> return value. If the caller wants to ignore this design, they >can, >>> but they are not using the function as it was designed. If they >>> pass a function return straight into it, they have no way of >>> capturing the change to $v which the author intended them to >see. >>> >>> >>> The value supplied to f1() is return value. >>> In languages, there are literal, constant and variable. Return value >is >>> variable. >>> >> >> No, a return value is a value - it is the result of some computation >which >> has not yet been assigned to a variable. This is perhaps more obvious >with >> an operator: "1 + 2" is not a variable, it is the value 3; >internally, a >> temporary variable is probably used to hold that value, but that >temporary >> variable is never accessible to the programmer. If you have function >> add($a, $b) { return $a + $b; }, then add(1,2) is still not a >variable in >> any meaningful sense. > > >Value is vague term. I would like to use "expression". Expression is >anything that has value. >Variables/constants are values that have actual storage. >Literals are values that may not have actual storage. > >Joe pointed out PHP treats temporary variable differently. I suppose >temporary variable is created >for values not used as usual variable. e.g. Function return value. > >It may be the thing we need to reconsider. >Temporary variable is an variable after all. It may be used in context >that >is changed then discarded. > >Even if we raise errors for temporary variables, it's better to raise >_the_same_error_ where is it allowed. > ><?php >define('MYERROR', -1); >function &f1() {return -1;} // E_NOTICE rather than E_STRICT >function &f2() {return MYERROR;} // E_NOTICE rather than E_STRICT > >$v = f1(); >$v = 2; >var_dump($v); > >$v = f2(); >$v = 2; >var_dump($v); >?> >http://3v4l.org/9LdkK#v551 > >I understand that return by ref and returning literal/constant is >contradictional, yet >it seems too much care for developers. Developer may simply return >value >that >indicates some error in return by ref function should be allowed w/o >error. >IMHO. > > > >> It's better to keep basic rule. IMHO. >>> >>> $top = array_pop(f2()); >>> >>> is better than >>> >>> $v = f2(); >>> $top = array_pop($v); >>> >>> Is there anyone who likes latter? >>> >> >> array_pop() is a stack-manipulation function, so the latter is the >correct >> use, with $v going on to be used as the rest of the stack. If you're >using >> it for something other than stack manipulation, neither is correct, >because >> it's the wrong choice of function. > > >User may use array_slice() for it, but array_pop() is intuitive what it >does and works >perfectly except unneeded error. Therefore, user surprises what is the >"Only variable >references should be ..." means. > >Anyway, I wrote a blog about this spec many years ago and the entry is >accessed >constantly even today. I suppose PHP7 will have more >intuitive/flexible >parsing for >complex expressions(e.g. f()[2]->method(), etc, isn't it?), then this >spec >may confuse >more users. > >We don't need unwanted side effects, therefore this change should be >done >carefully. >I wouldn't argue with this. If removing "Only variable references >should be >..." error is >feasible, I would like to propose this change.
You keep talking about these "errors" being a burden on the programmer, but accepting that in principle it would be better to avoid such situations, so I want to reiterate: these are Strict Standards hints - they tell the programmer "we're not going to stop you doing this, but you might want to find a better way to write it". This seems like a perfect balance to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
