Hi!
>> No. There's no reason for null to exist if isset returns true on
>> null. If one doesn't understand that, one should not be using
>> null at all.
>
>
> Nonsense.
Oh, thank you! That's a good start for a polite argument.
> It just means that one isn’t using null the way you do.
No, it means one isn't using null the way it is intended to be used in
the language. Which is your right, but then please don't demand language
to change when it doesn't work as you expected. You voided the warranty,
you bear the consequences.
> Programmers have been using null like this for decades, e.g., C
> strings. It’s also quite common in databases, where, at least with
PHP is not C, in fact C does not have null value (akin to PHP's one)
at all. C has zero-valued pointer which is sometimes used as "no
value" in certain contexts but the semantics of how C and PHP works in
this area are completely different.
> MySQL, null happens to translate directly to PHP null when data
> are queried. And frankly, I see nothing wrong with recognizing that
> a
SQL null is not a regular value, and you are in for big surprises if
you try to use it as a regular value. PHP has much less surprises, but
if you know what NULL is in SQL, you should not be surprised by PHP's
null behavior.
> functions do. As I said, they’re misguided, right up there with
> register_globals. (They lead to similar security bugs, too.)
Please do not bring "security" as some superman-argument, expecting
that is you say "security" your arguments suddenly become so much
stronger. There's no special security problem here besides the trivial
fact that if you write buggy code in security-sensitive context, you
get security issue. So please leave security out of it.
> Incidentally, what’s the difference, philosophically, between
> these two:
>
> $foo = null; var_dump(isset($foo)); //false
>
> $foo = [‘bar’ => null]; var_dump(array_key_exists(‘bar’, $foo));
> //true
The first is declaring variable to special value (null) that is
designed to return "empty" on isset/empty check. The second is
defining array key holding the same value. That's the difference. I'm
not sure what philosophical school you belong to, so I can't go there,
but in PHP that's pretty much it.
> If a variable that’s declared yet defined as null can’t “exist” as
> decided by isset(), why can an array element that’s declared yet
> defined as null “exist” as decided by array_key_exists()? Is the
Because these are two different functions doing different things.
That's like asking why strlen returns string length but fopen does not
return file length.
> symbol table really that different from an array? It gets weirder
> yet where the two start to overlap in user land:
>
> $foo = null; var_dump(isset($foo)); //false
> var_dump(array_key_exists('foo', $GLOBALS)); //true
What's weird in it? GLOBALS is specifically created construct to treat
global scope variables as array.
> I don’t understand how anyone can see this as being consistent and
> self-explanatory, especially if we assume the words ‘exists’ and
> ‘set’ to have their traditional programming meanings (‘set’
> meaning to assign a value and ‘exists’ meaning there’s an in-scope
> entry with the given name in the symbol table).
That's not what isset() does, however. As I already mentioned, null is
a special value with special semantics. If you insist on ignoring this
semantics, fine, but it's not PHP's fault then that you are surprised
by the result.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
