On Sep 16, 2015, at 11:14, Rowan Collins <rowan.coll...@gmail.com> wrote: > > Robert Williams wrote on 16/09/2015 18:37: >> The docs suggest that uninitialized variables are null, and the above makes >> it sound like that’s what you’re stating, too. But they’re not: they don’t >> exist at all, they’re uninitialized. > > As soon as you access them, you will get the value null. You can do > everything with them that you could do with a variable initialised to null.
As soon as you access them, you get an error, and then you get null. Yeah, one could register an error handler, but that’s a lot of fuss just to see if a variable really exists or just exists because you accessed it, and it pulls you out of context. Basically, there’s no (clean, very simple) way to identify that you’re about to step in a pile of poo before you step in it. >> If they were null, then PHP wouldn’t spit out errors about undefined >> variable accesses > > Once again - PHP does not spit out errors when you access an undefined > variable. It spits out Notices in case you've done it by mistake. Maybe > you're thinking of JavaScript? In our shop, notices are most definitely errors. And notices aren’t graceful error handling. I think PHP also also regards them as errors (thus the ability to catch them with an error handler) - it’s just a lower grade of error. > I don’t think it’s a huge gap in the language, but it’s a definite gap, and > it’s one that many less-experienced programmers fall right into with safety > checks. > > There is no safety check required. If you care about eliminating the Notices, > then initialise all your variables properly, and you will never have an > uninitialised variable (so a runtime check for one would be pointless). If > you don't care about eliminating the Notices, then simply treat uninitialised > variables as Null, and they will work absolutely fine. That’s great in theory, but in practice, programmers’ code must frequently collaborate with other people’s code, often code from outside their organization. In these cases, they don’t have the control to just fix the problem on the other side. And in some cases, like with config files that set bare variables, there’s really nothing wrong with the way it’s done that needs to be fixed. Some folks might prefer to use a different model, but that’s just a preference. Adding an exists() function doesn’t go against the foundation of PHP. It just fills a gap. Again, I can define variables, and I can destroy them, but I can’t tell if they’ve already been defined. In a dynamic language like PHP, I really don’t understand how folks can *not* see that as an oversight. Further, we can do this for everything else… constants, array elements, object properties, functions, and even classes, so why not variables? There's even have precedence for controlling behavior based on variable existence in extract(), so PHP itself does it in ways that directly affect the user, but the user can’t do it. Yes, there are workarounds for the gap. There are almost always workarounds in a sufficiently developed language, but that doesn’t mean there isn’t a gap. -Bob
signature.asc
Description: Message signed with OpenPGP using GPGMail
