Re: Isset question

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: > Hello internals, > > If anyone has a moment to answer this, it'd be appreciated... > > -- > isset($x); => false > is_null($x) => Notice: undefined variable $x > > -- > $x = null; > isset($x); => false > is_null($x) => true > > The question is *why* does isset() report false on a variable that > is set to NULL? Is there any way to tell if a variable isset and > is_null without generating an error? > > It doesn't seem that this behavior is consistent with the meaning of > isset(), or the errors that are generated when a variable is not set. > > > Thanks. > > -- > Best regards, > Jason Garber mailto:jason@ionzoft.com > IonZoft, Inc.