Craig Francis wrote on 14/09/2015 12:46:
So yes, in the example above, an isset() would work, but I was trying to show why I don't think it's odd to "suppress a warning for a plain variable" when it does not exist.
Yes, and I agree that this example shows a reasonable use of isset(). It works fine as it is, and doesn't need any functionality adding or removing.
Actually, I think they do use an array to store the values, then do an extract() to make them local variables in the View (keeping the variable names shorter and easier to read).
Incidentally, I've always wondered why extract() would ever be useful in modern code, but I agree that if you don't want/need the overhead of a separate template compiler, that approach actually works quite nicely.
Yes, it is mis-used with arrays, but I would still argue that a single exists() function would work better for all of these examples when testing if they exist. And I would hope that no-one was using an unset() as something distinctly different from a NULL value.
If you don't need the ability to distinguish unset() from null, what would any of these examples gain from using exists() over isset()?
I agree that we should not have a function that distinguishes between unset($foo) and $foo=null.
But if you take the "is null" check out of isset(), that's exactly what you have; that's why the "is null" check is there in the first place.
That's why I said I could agree with an exists() function (not under that name) as a nicer syntax for array_key_exists(), but not as a replacement for isset().
You could have an exists() function which works like array_key_exists() on an array, but identically to isset() on plain variables, but I think that would just be confusing. Hence my suggestion that any new function throw an error if given something other than an array access.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
