Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75215
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dds.nl from 85.17.251.144 cause and error)
Date: Thu, 3 Jul 2014 13:18:42 +0200 (CEST)
To: Tjerk Meesters <tjerk.meesters@gmail.com>
cc: PHP Internals <internals@lists.php.net>
In-Reply-To: <CAHMUw2HQPSqY8DvfKigHFc7AJcPU6bwa4hgmpN5tsh8fMzh+6Q@mail.gmail.com>
Message-ID: <alpine.LNX.0.999.1407031238420.2935@swan.dds.nl>
References: <alpine.LNX.0.999.1407031108350.526@swan.dds.nl>
 <CAHMUw2HQPSqY8DvfKigHFc7AJcPU6bwa4hgmpN5tsh8fMzh+6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Subject: Re: [PHP-DEV] not_null function
From: xen@dds.nl (Xen)

Hi Tjerk,

appreciate the response.

On Thu, 3 Jul 2014, Tjerk Meesters wrote:

> For this particular case I would use this: if (isset($a))

A name like "isset" is semantically incorrect because its name implies 
that you use it to check whether a variable is, well, ...., /set/.

A variable that is null is not necessarily not set. If that was true, then 
the following code would be meaningless:

class A {
   var $field = null;

   function x() {
     if (!isset($this->field)) {
       echo "field is not set";
     }
   }
}

Or rather, this above code IS meaningless. Let's call it "if 
(is_meaingless($code)) self_destruct();" ;-).

So really, isset is not a proper way to test null because you KNOW you 
have set it yourself. Further, it is more specific (more primary) than a 
null test. So you could use "not_null" and that could be the equivalent of 
"isset($a) && $a !== null" but not the other way. isnull/not_null depend 
on isset, not the other way around. So you cannot have isset include, 
imply or insinuate that something is also not null, but you CAN have 
isnull/not_null include, imply or insinuate that something is also set.

Actually, that is only true for not_null. For something to be not_null it 
also needs to be set. But something that is null also needs to be set. So 
there would be a special usecase where you check (isset && isnull) and the 
interpreter should give an error if isnull is called on an unset variable.

But this special use case is very rare. Normally a null is returned from a 
function, or you have set it yourself. So it is a very rare occassion that 
you both need to check whether a variable exists, and you also want to 
know whether it is null. As soon as you add "not_null" to your language, 
this is true.

If you do not add "not_null" to your language, then isnull /CAN/ perfectly 
imply or may include an unset variable. Because then it would be the only 
way to express the not-null condition.

Just semantics, my friend. Just meaningful language versus meaningless 
language constructs.

> There's also `is_array()`, `is_bool()`, etc. so changing only `is_null()`
> would be a big wtf ;-)

Not true. Those are similar cases to the "is_single()" of WordPress 
because "array()" is completely ambiguous because it is also a cast or a 
construction construct, same for bool. This is not true of null(), null() 
can never be a cast or anything else, but it would also be somewhat 
ambiguous since it could mean any number of other things. Null is rather 
primary, foundational. "null()" as a function would not be good.

Same with "if (false())" would also not be good.

But in any case, if you did want to change is_array() etc (and I guess you 
would need to to stay consistent) that just agrees with what I said in my 
mail, that a great many languges have function names like that. Except 
that camel case languages don't. I never liked the my_function_name format 
but I have to use it in PHP for consistency and Python has some 
camelCase libs but it is just too unsettling to mix the two.

But honestly I don't care about is_array() and the like because how much 
do you use it really? And like I said, it is similar to is_single() and 
is_category(). It falls in a row of tests that could be considered a 
switch statement.

But isnull is atomic. It is unique. It doesn't test for type. There can be 
3 million tests for is_type() if you wanted. If you gave them all "istype" 
names, it would become unreadable. In a camelCase object language you 
would also not do object.isArray() but it would be some static method 
doing Object.isArray(var) so you really need to know where to put what.

isnull and isset are completely fundamental and basic and elementary and 
final and immutable constructs and is_null should not even fit into the 
category that isset sits in. I know "null" is a value so "$a == null" is 
fine and you cannot do that for isset but still is_null is so essential 
and important as a shorthand that it warrants treatment as a language 
construct instead of as a function.

So I think you can make a proper case for only doing the following:

- isset only tests an alias (reference) being attached to a variable 
(bucket)
- not_null returns (isset($a) && $a != null)
- isnull returns ($a == null)

But how many times really do you check for null?

I think if you would statistically analyse all PHP code the number of 
"is_null()" expressions is dwarfed by the number of "!is_null()" 
expressions. The only reason people use is_null is so that they can turn 
it into !is_null(). Personally, if I have a reason to test for null 
specifically, I just write "== null" because it explains more clearly what 
the value means to me.

not_null doesn't actually test for a value. It tests for "is set and has 
any value". You don't care about the null value when you use not_null.

So basically not_null is also a more "core" thing to do and you are 
currently abusing "isset" for this. Who then needs is_null()? It is a 
superfluous language element. Just get rid of is_null, introduce not_null, 
and fix isset. That's what I would do.