I really don’t understand the resistance to this type of change, other than knowing that a fix will necessarily be messy. The fact is, PHP distinguishes between a variable that has been declared but defined to null and one that hasn’t been declared. The value of the first may safely be assigned, compared, referenced, and so on, while attempting any of those things on the second one results in an error message. The question of whether relying on those differences is philosophically acceptable is a moot point: they *are* different, period, and the rest of the language should acknowledge and support that — just as do most other languages with a similar design (e.g., JavaScript).
Beyond that, the philosophical debate is clearly settled in the real world of code. One glance through the comments on the isset() documentation page, not to mention the bug reports and the discussions on the lists, shows that people have long struggled with this. Based on code I’ve seen from fairly experienced developers, the confusion around this has probably led to millions of production bugs, many of them in the areas of validation and security. When a particular aspect of a language's design promotes bugs to such an extent, it needs to be revisited. I’m not sure what a good solution is, however. Changing isset() will have consequences: making it return true for null will magically fix a lot of bugs out there, but it’ll also break code where the programmer understood how it really works. Adding a parameter to control it is ugly. Extending defined() to variables might be a good choice, as it’s already doing for constants exactly what’s needed for variables; the only downside is that it would be better-named declared() than defined(), but that’s the case for constants, too, so I can live with it. For now, isset() and empty() can continue to work as-is but perhaps with a notice and deprecation when used with undeclared variables. -- Bob W.
signature.asc
Description: Message signed with OpenPGP using GPGMail
