On Sep 14, 2015, at 16:06, Stanislav Malyshev <smalys...@gmail.com> wrote:
>
>>> 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.
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.
>> 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.
It really seems to me that PHP is fundamentally confused in how it wants to
treat null. It clearly has the concept of an undefined variable: variable
existence is referenced throughout the docs along with null-ness (e.g., the
docs for isset() say it returns true if the variable, "is set and is not null"
and if the variable, "exists and has value other than null"), it throws
undefined errors for using variables that aren't defined, and it even has an
unset() construct that leads to an undefined variable that fails isset(). Yet,
it also defines undefined variables as being null -- which is it? Even
is_null() is caught up in this: it will throw an undefined error if passed an
undefined variable while also returning true. Why an error for a value that
supposedly fits the definition of null?
>> 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.
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 true because null
handling in PHP is clearly confusing to a lot of folks, and any confusing API
(buggy or not) will tend to lead to application-level security bugs if that API
is often used in security contexts. Hasn't a bunch of work recently been
completed with hashing and encryption APIs for this very reason? Same idea.
I also mentioned the security issue parenthetically, as a side-note, so please
don't accuse me of overplaying the security card. My main point there was that
isset() and empty() were ill-conceived.
And again, who's doing the bashing here? Ease off a bit -- I'm really not
trying to attack you at all.
>> 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.
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 keep being paired together in this
thread and why people keep using one when they should be using the other. If we
allow that, then it would make sense for them to function similarly.
Okay, so to bring this home:
1 PHP defines null to include variables that have "not been set"
2 PHP also defines null to include variables that have been unset()
3 Variables can be explicitly set to null
All of these are null. And yet:
4 Calling isset(), which is documented to return true on null, on 1, 2, and 3
will only return true for 3.
How's this consistent?
Returning true on 1 and 2 suggests clearly that PHP does distinguish between
undefined variables and null variables. This supposition is also supported by
numerous mentions of these concepts in the docs and by the various undefined
error messages that PHP produces. It goes off the tracks, however, when it
returns true for 3.
IMHO, PHP went south in its design when it tried to declare undefined variables
as null. They're not; they're undefined. Beyond isset/empty/is_null, however,
the rest of PHP seems to accept this. Even the three deviant functions tacitly
acknowledge the issue in their documentation, e.g. with isset()'s existence
requirement as part of a compound statement ("exists and has value other than
null"). PHP falls short, however, in not providing a way to independently test
each part of that compound statement.
Ideally, we would reverse course on the undefined-is-null declaration then
adjust isset/empty/is_null accordingly, but I realize that opens a large can of
worms. Providing a simple exists() function doesn't solve the root issue, but
it at least gives a way to directly test for a very real condition: the first
half of the isset() compound requirements statement. If we can do that, we will
have what we need to mostly regard the null design error as an academic matter
with relatively little real-world consequence going forward.
Regards,
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
