Re: Type of form element

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, October 31, 2005 2:53 pm, Marcus Bointon wrote:
> Take apart this operation:
>
> $a = isset($myarray['a']);
>
> Implicit in this simple line is a 'hidden' step which is to look up
> the index 'a' in $myarray to get its value before testing if it is

No.

I don't care what the value is, and isset() does not need to look up
the value.

If you want to post the C source from PHP CVS that shows that PHP
actually looks at the value to decide if the index is there, go right
ahead.  You'll rapidly find out that you're just wrong.

> set or not. The issue I have is that that step's existence is being
> overlooked. That line could also be written:
>
> $a = !is_null($myarray['a']);
>
> Either way, if $myarray['a'] does not exist, its value will be
> regarded as null (and as such, isset and !is_null would give correct
> results as a consequence of this convenient side-effect), but I would
> also fully expect to receive an undefined index notice as you have
> explicitly looked up an array index that does not exist. If you used
> other functions the same way you're using isset, you would see
> nothing wrong with this:

You still don't get it.

isset($myarray['a']) does *NOT* *NOT* *NOT* do what you are claiming
it does.

It *JUST* checks the array *KEYS* to see if 'a' is in the *KEYS*

It doesn't try to "look" into the value to see what's there.

It does not do an array lookup and check the value and see if NULL is
"in" the array.  If the key isn't there, the key isn't there, and it's
not set, and there isn't going to be a warning for trying to use a key
that's not there because PHP DOES NOT USE THE KEY TO DO A LOOKUP.

It just doesn't do that.

That's the way isset() works, by design, and as documented:

http://php.net/isset
"This also work for elements in arrays:"

It's worked that way since PHP3.0RC1, if not longer, and has been
documented to work that way all this time.

> $myarray = array();
> print $myarray['a'];
>
> but I would hope that you would have a problem with that. Why treat
> isset differently?

Errrrr.

Because isset() is a LANGUAGE CONSTRUCT which explicitly checks if the
KEY is valid, and if it's not, it DOES NOT DO A LOOKUP and it just
returns FALSE because the array key is NOT SET.

It's *NOT* a function.  The usual order of operations you assume to be
implicity, with the "lookup" for the key 'a' does not happen.  It
doesn't work like you think it works.  Never has.  Never will.

How many different ways do we have to say this, and how many times do
we have to point to the documentation?

isset() works for arrays.

It checks if the key is a valid key.

If it's not a valid key, it's not doing a lookup.  That key isn't set.
 It's called "isset()" and it works for arrays and that's the way it
*IS*

One last time:
isset($array['key']) does NOT LOOKUP THE VALUE IF 'key' IS NOT THERE,
by definition, it's "not set" and isset() return FALSE with NO LOOKUP.

Am I getting through yet?

Would you like to check the PHP source code to find the definition of
isset()?  Help yourself:
http://cvs.php.net/

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux