Here is one reason: $x = @$y[3];
What should isset($x) return if $y doesn't have an
index 3?
If php had distinct concepts of "undefined" (perhaps
this would be a software level undefined value) and
"null" (perhaps this would be a built-in user level
undefined value), things would work very differently.
In the example above $x would be "undefined" as would
any unused variable, and there would be a way to check
whether a variable was undefined. If you never use
null as a handy way to indicate user level undefinedness,
you won't have any problem with the lack of distinction.
"null" _is_ php's "undefined". As such, it makes sense
for $x to be null and isset to return false. If you
try to use "null" to indicate, for example, that the user
hasn't yet responded to a question (or that a value from a
database was "null"), you will likely have moments of
frustration.
That sounded biased, so I have to point out that
making the aforementioned distinction is not a
panacea. It assumes only two layers: software and
user. Even if the distinction were made, if the software
had 2 or more layers, you could still end up with
the same issues. There would need to be conversions
between undefined and null at the layer boundaries.
I'm typically just a lurker here and have only
contributed a few lines of code (and those didn't
even make it in), so these are just the observations
of a user that has played with the internals a bit.
- Todd
On Tue, 2004-12-07 at 23:39, Jason Garber wrote:
