Hi Rowan, On Thu, Jun 11, 2015 at 5:59 PM, 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 > > > [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? For example, getting NULL handler as the default. This is useful like $v=NULL;$v[1][2][3]; > 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 those who are familiar with NULL in RDBMS might make sense returning NULL for all. NULL is special value and how it should be behaved is debatable. Raising some kind of error for all would be nicer including $v=NULL;$v[1][2][3]; IMO. Less exceptions are better. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
