On 11 June 2015 at 09:59, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Yasuo Ohgaki wrote on 11/06/2015 00:50: > >> If PHP should return NULL always against NULL variables, we may be better >> to >> reconsider these behavior. >> >> [yohgaki@dev Download]$ php >> <?php >> $v = NULL; >> $$v; >> >> >> PHP Notice: Undefined variable: in - on line 3 >> > > This is not complaining that $v is NULL, it is warning you the same as if > you wrote $v = 'some_name_you_never_assigned_to'; $$v; > > Somewhat surprisingly, you can actually assign to the variable whose name > is NULL: http://3v4l.org/5pXJg This is actually just converting $v to a string and using this as the variable name to look up in the symbol table: http://3v4l.org/Z1fWs (obvious I suppose, just to clarify) > > > [yohgaki@dev Download]$ php >> <?php >> $v = NULL; >> $v(); >> >> PHP Fatal error: Uncaught EngineException: Function name must be a string >> in -:3 >> Stack trace: >> #0 {main} >> thrown in - on line 3 >> > > This one has given a different message because of it being a non-string > value, but would be equally fatal if you tried to call any undefined > function. Would coercing NULL to an imaginary function which returns NULL > actually be useful for anything? > > I don't care much whether these yield NULL always or raise >> error/exception, >> but there should be consistency. >> > > I see no reason why these cases need to be consistent, just because they > both involve NULLs. It's all about the action you invoke, not just the > value something's interpreted as. I think what Yasuo is saying is that the function symbol lookup has a type check and an early bail-out if the type doesn't make sense - even though in theory the same string cast behaviour could be applied to dynamic function calls. I'm inclined to agree that we should have consistency here, and that the current behaviour in a function context is the correct one. A couple of (IMO) good arguments for this: - The function behaviour gives a more explanatory and useful error message - This is definitely a programming error, there is no valid reason to use NULL as a variable name in this manner. It amounts to what many/most other languages would consider to be a "null pointer exception" or equivalent, and the more useful error message may help track down the error quicker (one might look for a case where the empty string was assigned, instead of looking for a case where it may be NULL). > > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
