Hi! > Apologies, no offense intended, but you do realize that you > essentially said that any programmer who doesn't agree with what you > profess is the One True Way, is doing it wrong? This type of > statement has been made several times in this thread, and it's > annoyingly dismissive. Given how PHP has evolved, and how many > architectural inconsistencies there are, I'm not so sure there is a > One True Way.
You make it sound like I'm founding a new religion here. But I am just explaining how this particular feature was designed to work. And yes, for many features, there is the right way and wrong way to use it. Nobody prohibits you from using the "wrong" way - in fact, hackers are famous for doing that and achieving many spectacular results. But you must realize if you do that, you have to familiarize yourself with the consequences. In this case, if the consequences surprise you, I can not fault the language. > Re-read what I said. I didn't say any of this was a security bug. I > said it can lead to security bugs. And that is, I think, undeniably Anything can lead to security bugs. "+" operator can lead to a security bug if used incorrectly. But so far there was no specific case outlined that makes it particularly susceptible to security issues (unlike, say, register_globals). So let's leave security out of it. > Clearly, they're different functions, but I think they're doing > something different only so far as they operate in different > contexts. Their purposes are closely related, IMHO, which is why they They are related, but still different, and this difference needs to be understood. isset() deals with variable values, array_key_exists() deals with hash *keys* - that's why it has "key" in its name - and not values. It is important to understand the difference. > 1 PHP defines null to include variables that have "not been set" 2 No, not really, PHP does not define that. Rather, PHP has a special value "null", which purpose is to be special value that returns "empty" when checked with isset/empty. That's its purpose in life. When asking for the value of non-existing variable, null value is substituted. Also, null value is used to initialize variables lacking other initializers. > PHP also defines null to include variables that have been unset() No, PHP does not define anything like that. In fact, unset() means the variable is destroyed and does not exist (of course, excepting refcount etc. issues). Null does not feature in this story at all. > Variables can be explicitly set to null That is true. > 4 Calling isset(), which is documented to return true on null, on 1, isset() is documented to return true on null? Where? That must be a bug in documentation. In fact, http://php.net/isset clearly states: Determine if a variable is set and is not NULL. > Returning true on 1 and 2 suggests clearly that PHP does distinguish > between undefined variables and null variables. This supposition is That's not a correct description. Correct description is that if you ask for a variable and it is not defined, null value is substituted. There's a difference between "coffee and tea is the same thing" and "if you don't have coffee, I'll drink tea" :) > IMHO, PHP went south in its design when it tried to declare undefined > variables as null. They're not; they're undefined. Beyond That's your opinion. Mine, for example, is that it is a very useful feature. In any case, PHP is implemented this way, and there's no way to change it while the result remaining PHP language. If it makes PHP unsuitable for you, sorry, but that's what PHP is. I don't think it makes a lot of sense to discuss changing basic semantics of PHP engine - I don't think this is going to happen. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
