# not_null function

- Thread: https://externals.io/message/75209
- Original archive: https://news-web.php.net/php.internals/75209
- Started by xen@dds.nl on 2014-07-03T09:40:05+00:00
- Messages: 33
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/75209.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #75209 — xen@dds.nl — 2014-07-03T09:40:05+00:00

URL: https://externals.io/message/75209#75209

Heya,

I was just wondering about something.

It seems way more natural and flowing to have and use a "not_null" 
function in addition to some "is_null" that currently exists.

The reason is that most of the time you are not checking null condition, 
you are really checking the non-null condition.

But a line like "if (!is_null($a))" feels like there are two verbs in it.

It is like you are saying "if $a is not is null".

It is different for the "empty" function because there is no "is_" prefix 
in it. So "if (!empty($a)) feels completely sane.

So generally I will *want* to test a null condition but I just hope my 
variable won't contain anything that evaluates to false and just test "if 
($a)".

If there was a not_null() I would use that instead, because "if 
(not_null($a))" only contains one "verb" instead of two.

And I would define that helper function myself, but I don't want to write 
code that another person would not be able to run just because not_null is 
not defined in his library.

--------
In general I believe this is rather a problematic feature of most 
languages.

The "if" statement implies a verb, but many functions and methods also 
contain a verb in their name.

This seems to be only the case for the "is" verb. I know in my language 
(Dutch) the "to be" verb (zijn) is treated differently from all other 
verbs when it comes to the adverb/adjective difference.

When you state "I am good" the adjective is used, but "I work good" should 
be "I work well". The adjective applies to the subject "I" but the adverb 
applies to the verb "work". I guess there are all sorts of mixtures, "I am 
well" is also used. But I think it is improper.

Thus, "if (has_members())" feels natural because it uses a different verb 
replacing the default "is".

But "if (is_null())" feels odd because "if (null())" would say the same 
thing only more concise and more natural as far as if statements go, or at 
least it seems that way to me.

Personally I try to avoid those "is_something" functions whenever I can. 
It is not so much an issue if it is some rarely used library call.

Like WordPress has functions like "is_single()" which returns a boolean 
indicating whether the currently loaded page is a single post display.

But notice that "if (single())" would give very little information as to 
what you were actually testing. There is no parameter, and just "single" 
would be so general that it would completely obfuscate the fact that it 
had to do with WordPress. It would have to become "page_is_single()" 
although "page" is (improperly) dedicated to a special type of post that 
sits outside of the regular post structure. They ought to rename it to 
"staticpage" or "static". "page_is_single" and "page_is_home" and 
"page_is_category" would be more descriptive.

But in any case, this language incongruency is most annoying with core 
functions you have to use all the time, or would be using all the time if 
they were okay.

So my suggestion would be to consider introducing at least "not_null". 
"isset" seems to be a different category, if only because the verb is not 
visually separated from the condition.

So "if (isnull($a))" would again be more natural. But because the verb is 
visually separated using the underscore, you get two verbs in your mind. 
Perhaps creating an "isnull" alias and then deprecating the "is_null" 
function would be best.

Regards,

Bart Schouten

ps. please "reply all" for I am not subscribed as of yet.

---

## #75211 — Tjerk Meesters — 2014-07-03T10:24:53+00:00

URL: https://externals.io/message/75209#75211 · In reply to: #75209

Hi Bart,




> Heya,
>
> I was just wondering about something.
>
> It seems way more natural and flowing to have and use a "not_null"
> function in addition to some "is_null" that currently exists.
>
> The reason is that most of the time you are not checking null condition,
> you are really checking the non-null condition.
>
> But a line like "if (!is_null($a))" feels like there are two verbs in it.
>

For this particular case I would use this: if (isset($a))

For undefined variables it will return `false` and for defined variables
it's equivalent to the expression `$a !== null`.


> It is like you are saying "if $a is not is null".
>
> It is different for the "empty" function because there is no "is_" prefix
> in it. So "if (!empty($a)) feels completely sane.
>
> So generally I will *want* to test a null condition but I just hope my
> variable won't contain anything that evaluates to false and just test "if
> ($a)".
>
> If there was a not_null() I would use that instead, because "if
> (not_null($a))" only contains one "verb" instead of two.
>
> And I would define that helper function myself, but I don't want to write
> code that another person would not be able to run just because not_null is
> not defined in his library.
>
> --------
> In general I believe this is rather a problematic feature of most
> languages.
>
> The "if" statement implies a verb, but many functions and methods also
> contain a verb in their name.
>
> This seems to be only the case for the "is" verb. I know in my language
> (Dutch) the "to be" verb (zijn) is treated differently from all other verbs
> when it comes to the adverb/adjective difference.
>
> When you state "I am good" the adjective is used, but "I work good" should
> be "I work well". The adjective applies to the subject "I" but the adverb
> applies to the verb "work". I guess there are all sorts of mixtures, "I am
> well" is also used. But I think it is improper.
>
> Thus, "if (has_members())" feels natural because it uses a different verb
> replacing the default "is".
>
> But "if (is_null())" feels odd because "if (null())" would say the same
> thing only more concise and more natural as far as if statements go, or at
> least it seems that way to me.
>
> Personally I try to avoid those "is_something" functions whenever I can.
> It is not so much an issue if it is some rarely used library call.
>
> Like WordPress has functions like "is_single()" which returns a boolean
> indicating whether the currently loaded page is a single post display.
>
> But notice that "if (single())" would give very little information as to
> what you were actually testing. There is no parameter, and just "single"
> would be so general that it would completely obfuscate the fact that it had
> to do with WordPress. It would have to become "page_is_single()" although
> "page" is (improperly) dedicated to a special type of post that sits
> outside of the regular post structure. They ought to rename it to
> "staticpage" or "static". "page_is_single" and "page_is_home" and
> "page_is_category" would be more descriptive.
>
> But in any case, this language incongruency is most annoying with core
> functions you have to use all the time, or would be using all the time if
> they were okay.
>
> So my suggestion would be to consider introducing at least "not_null".
> "isset" seems to be a different category, if only because the verb is not
> visually separated from the condition.
>
> So "if (isnull($a))" would again be more natural. But because the verb is
> visually separated using the underscore, you get two verbs in your mind.
> Perhaps creating an "isnull" alias and then deprecating the "is_null"
> function would be best.
>

There's also `is_array()`, `is_bool()`, etc. so changing only `is_null()`
would be a big wtf ;-)

You could propose to change `isset()` into `is_set()` though =D


> Regards,
>
> Bart Schouten
>
> ps. please "reply all" for I am not subscribed as of yet.
>
> --
> 
> 
>
>


-- 
--
Tjerk

---

## #75214 — Lazare Inepologlou — 2014-07-03T11:10:40+00:00

URL: https://externals.io/message/75209#75214 · In reply to: #75209

2014-07-03 11:40 GMT+02:00 Xen <xen@dds.nl>:

> Heya,
>
> I was just wondering about something.
>
> It seems way more natural and flowing to have and use a "not_null"
> function in addition to some "is_null" that currently exists.
>
> The reason is that most of the time you are not checking null condition,
> you are really checking the non-null condition.
>
>
Well, there is a better alternative:

if ( $x === null ) ....
if ( $x !== null ) ....

This syntax has also the advantage that it is marginally faster as there is
neither a function call nor a negation involved.
:)


Lazare INEPOLOGLOU
Ingénieur Logiciel

---

## #75215 — xen@dds.nl — 2014-07-03T11:18:42+00:00

URL: https://externals.io/message/75209#75215 · In reply to: #75211

Hi Tjerk,

appreciate the response.



> 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.

---

## #75216 — Kris Craig — 2014-07-03T11:23:26+00:00

URL: https://externals.io/message/75209#75216 · In reply to: #75211

On Thu, Jul 3, 2014 at 3:24 AM, Tjerk Meesters <tjerk.meesters@gmail.com>
wrote:

> Hi Bart,
>
>
> 
>
> > […]
>
> For this particular case I would use this: if (isset($a))
>
> For undefined variables it will return `false` and for defined variables
> it's equivalent to the expression `$a !== null`.
>
>
> > […]
> is
> > […]
> verbs
> > […]
> should
> > […]
> am
> > […]
> at
> > […]
> had
> > […]
>
> There's also `is_array()`, `is_bool()`, etc. so changing only `is_null()`
> would be a big wtf ;-)
>
> You could propose to change `isset()` into `is_set()` though =D
>
>
> > […]
>
>
I've found over the years that a lot of developers, particularly those who
specialize in languages other than PHP, use `is_null()` when what they really
want is empty().

The problem with `is_null()` and the === operator is that PHP will throw a
notice if the variable is not set.  If you're just looking for whether a
variable is blank or not, empty() will handle that whether the variable is
set or not.  Personally, I don't understand why we need `is_null()` at all in
its current form, since it's exactly the same as === NULL, except that it
doesn't perform as well.

Rather than removing it, I think `is_null()` should be changed into a
language construct like isset() and empty().  That way, people could pass
undefined variables to `is_null()` without triggering notices.  It'd
basically be the same as empty, except that it would only return true of
the value is exactly NULL.

I.e. it'd go like this:

empty( $var ) is functionally equivalent to isset( $var ) && $var != `NULL` 
is_null( $var ) is functionally equivalent to isset( $var ) && $var !== `NULL` 

I think that would make a hell of a lot more sense than the way `is_null()`
works now.  Thoughts?

--Kris

---

## #75217 — Kris Craig — 2014-07-03T11:25:20+00:00

URL: https://externals.io/message/75209#75217 · In reply to: #75216

>
>
>
> On Thu, Jul 3, 2014 at 3:24 AM, Tjerk Meesters <tjerk.meesters@gmail.com>
> wrote:
>
> > […]
> I've found over the years that a lot of developers, particularly those who
> specialize in languages other than PHP, use `is_null()` when what they really
> want is empty().
>
> The problem with `is_null()` and the === operator is that PHP will throw a
> notice if the variable is not set.  If you're just looking for whether a
> variable is blank or not, empty() will handle that whether the variable is
> set or not.  Personally, I don't understand why we need `is_null()` at all in
> its current form, since it's exactly the same as === NULL, except that it
> doesn't perform as well.
>
> Rather than removing it, I think `is_null()` should be changed into a
> language construct like isset() and empty().  That way, people could pass
> undefined variables to `is_null()` without triggering notices.  It'd
> basically be the same as empty, except that it would only return true of
> the value is exactly NULL.
>
> I.e. it'd go like this:
>
> empty( $var ) is functionally equivalent to isset( $var ) && $var != `NULL` 
> is_null( $var ) is functionally equivalent to isset( $var ) && $var !==
> `NULL` 
>
> I think that would make a hell of a lot more sense than the way `is_null()`
> works now.  Thoughts?
>
> --Kris
>
>
Typo correction:

empty( $var ) is functionally equivalent to isset( $var ) && $var == `NULL` 
is_null( $var ) should be functionally equivalent to isset( $var ) && $var
=== `NULL` 

--Kris

---

## #75218 — xen@dds.nl — 2014-07-03T11:30:07+00:00

URL: https://externals.io/message/75209#75218 · In reply to: #75214

> Well, there is a better alternative:
>
> if ( $x === null ) ....
> if ( $x !== null ) ....
>
> This syntax has also the advantage that it is marginally faster as there is
> neither a function call nor a negation involved.
> :)


This is semantically wrong because a programmer testing for not-null is 
not testing for the negation of is-null.

That is because null is not really a value. It is the absence of value. 
The absence of any value is not the negation of the presence of a 
....value that doesn't exist.

In the programmer's mind, "null" CAN have a value indeed but in that case 
he has picked it himself. In that case it would be semantically sound for 
him to check ($a == null).

But most of the time you don't want to know whether something is null, you 
want to know whether something has any value other than null (whether it 
has a value at all).

Therefore, usually, checking "$a != null" is not entirely meaningful 
because you don't really care about that value you are mentioning, it has 
no meaning to you. This is what makes it meaningless.

All of the terms in a sentence must have meaning for the entire sentence 
to have full meaning.

The absence of any value is a meaningful concept that ought to be directly 
testable. But you test it by asking for the /presence/ of any value. And 
if you *did* want to test for the absence, you would ask

"does it have any value?"

Just try to say this in English:

"doesn't the cup have anything in it?" or
"does the cup not have anything in it?"

You can see the meaning changes completely from what you intend.

In natural language you don't do that. You say

"/IS THERE A PRESENCE/" or "is there a contents"? You don't ask for the 
negation of the negative, because it has a very different meaning.

---

## #75219 — Pierre Joye — 2014-07-03T11:35:52+00:00

URL: https://externals.io/message/75209#75219 · In reply to: #75209

hi,



> But a line like "if (!is_null($a))" feels like there are two verbs in it.
>
> It is like you are saying "if $a is not is null".
>
> It is different for the "empty" function because there is no "is_" prefix in
> it. So "if (!empty($a)) feels completely sane.
>
> So generally I will *want* to test a null condition but I just hope my
> variable won't contain anything that evaluates to false and just test "if
> ($a)".

that's why we have is_null, and `NULL` is a type, not a value btw.

also isset is an operator, not a function. (referred in other replies).


> If there was a not_null() I would use that instead, because "if
> (not_null($a))" only contains one "verb" instead of two.


> And I would define that helper function myself, but I don't want to write
> code that another person would not be able to run just because not_null is
> not defined in his library.

is_null is consistent with the other is_* functions. A programming
language is not a natural language so grammatical or semantic
imperfections are totally valid.

between the is_* functions, isset or ?:, I do not see a need to add
the exact same features for a non technical reason.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75221 — Andrey Andreev — 2014-07-03T11:40:03+00:00

URL: https://externals.io/message/75209#75221 · In reply to: #75218

Hi,

The example that you gave just shows how null is practically
equivalent to a non-existing variable.


> Just try to say this in English:
>
> "doesn't the cup have anything in it?" or
> "does the cup not have anything in it?"

How'd you fit null in that? Asking if it's filled with air?

To me, this whole conversation is pointless. I don't like aliases
(like `is_null()` for !isset() in this case) and I don't see the point
in being _that_ extreme about semantics. In PHP you have at least 5
ways to check that a variable is not null, introducing yet another one
is not beneficial for anything in _practice_.

Cheers,
Andrey.

---

## #75222 — xen@dds.nl — 2014-07-03T11:40:19+00:00

URL: https://externals.io/message/75209#75222 · In reply to: #75217

> I've found over the years that a lot of developers, particularly those who
> specialize in languages other than PHP, use `is_null()` when what they really
> want is empty().
>
> The problem with `is_null()` and the === operator is that PHP will throw a
> notice if the variable is not set.  If you're just looking for whether a
> variable is blank or not, empty() will handle that whether the variable is
> set or not.  Personally, I don't understand why we need `is_null()` at all in
> its current form, since it's exactly the same as === NULL, except that it
> doesn't perform as well.
>
> Rather than removing it, I think `is_null()` should be changed into a
> language construct like isset() and empty().  That way, people could pass
> undefined variables to `is_null()` without triggering notices.  It'd
> basically be the same as empty, except that it would only return true of
> the value is exactly NULL.
>
> empty( $var ) is functionally equivalent to isset( $var ) && $var == `NULL` 
> is_null( $var ) should be functionally equivalent to isset( $var ) && $var
> === `NULL` 
>
> I think that would make a hell of a lot more sense than the way `is_null()`
> works now.  Thoughts?

For PHP, empty() is congruent because PHP works with buckets that have 
names. Personally, I consider that incongruent with programming itself, 
which is why I hesitate to use empty() because to my mind it implies a 
container and a variable is for me not necessarily a container that has 
one or more elements.

I guess if you can wrap your mind around that, it is fine, but I can't.

(!empty()) feels a lot better to me though than (!is_null()). I would 
definitely prefer that over the other.

But like I said in my other reply, I feel this "!empty" should get 
replaced with "not_null". If "!null()" were possible we'd have that but 
that is not an option no matter how far and hard you push it.

But we are on the same track and I like that :D!.

Regards,

Bart Schouten / Xen.

---

## #75223 — xen@dds.nl — 2014-07-03T11:47:29+00:00

URL: https://externals.io/message/75209#75223 · In reply to: #75219

> that's why we have is_null, and `NULL` is a type, not a value btw.
>
> also isset is an operator, not a function. (referred in other replies).

Alright, I stand corrected. But if `NULL` or null is a type, then comparing 
against it with == or === would also be wrong, right?

> is_null is consistent with the other is_* functions. A programming
> language is not a natural language so grammatical or semantic
> imperfections are totally valid.

That is just your unfounded opinion. In my view, which I believe is based
on the reasoning that I have espoused today, and just now, semantics are 
important because when things are meaningless they confuse us people. And 
us programmers are people who use language. And we require language to be 
natural and congruent so we can easily grasp it and avoid making errors. 
As to the "practical" implications that Andrey Andreeve mentioned in his 
reply.

I shall not reply to that message, but if you insist on arguing that 
semantics are irrelevant to any degree, you are basically arguing that 
there is a good reason to make language harder to understand, read and 
write because of some other reason that has nothing to do with it (like 
how many constructs already exist).

> between the is_* functions, isset or ?:, I do not see a need to add
> the exact same features for a non technical reason.

That is find if you see it that way, but I would rather have you answer 
with reasoning and arguments instead of just opinions and statements.

---

## #75224 — Tjerk Meesters — 2014-07-03T11:56:26+00:00

URL: https://externals.io/message/75209#75224 · In reply to: #75223

> 
>
>  that's why we have is_null, and `NULL` is a type, not a value btw.
> > […]
>
> Alright, I stand corrected. But if `NULL` or null is a type, then comparing
> against it with == or === would also be wrong, right?


Technically, yes; but in an expression `null` is also the representative
value for the type `null` as a convenient way to check whether something is
of the type `null`.


>
>
>  is_null is consistent with the other is_* functions. A programming
> > […]
>
> That is just your unfounded opinion. In my view, which I believe is based
> on the reasoning that I have espoused today, and just now, semantics are
> important because when things are meaningless they confuse us people. And
> us programmers are people who use language. And we require language to be
> natural and congruent so we can easily grasp it and avoid making errors. As
> to the "practical" implications that Andrey Andreeve mentioned in his reply.
>
> I shall not reply to that message, but if you insist on arguing that
> semantics are irrelevant to any degree, you are basically arguing that
> there is a good reason to make language harder to understand, read and
> write because of some other reason that has nothing to do with it (like how
> many constructs already exist).
>
>
>  between the is_* functions, isset or ?:, I do not see a need to add
> > […]
>
> That is find if you see it that way, but I would rather have you answer
> with reasoning and arguments instead of just opinions and statements.
>
>
> --
> 
> 
>
>


-- 
--
Tjerk

---

## #75225 — johannes@schlueters.de — 2014-07-03T11:56:38+00:00

URL: https://externals.io/message/75209#75225 · In reply to: #75223

> > […]
> 
> That is just your unfounded opinion.

null in PHP is a type as well as the only value for a variable of that
type. The is_* functions check for a type. As such it is consistent. We
won't add your special purpose function. You can add it to your library
if you need it. There were alternatives presented now let's end this
thread so we can spend the time on things we will actually do. Thanks
for understanding.

(I strongly suggest anybody to continue off-list if they see need to
continue this, we're spaming too many mailboxes otherwise)

johannes

---

## #75227 — Pierre Joye — 2014-07-03T12:15:38+00:00

URL: https://externals.io/message/75209#75227 · In reply to: #75223

> That is find if you see it that way, but I would rather have you answer with
> reasoning and arguments instead of just opinions and statements.

Well, as I said, I totally fail to see any kind of technical
requirements to do what was suggested in this thread. If you have one,
please post it :).

WIthout willing to troll, I see zero chance to see that happens, so
either there is a strong requirement for this change or one can do it
in userland as well as fixing all other grammatical or semantic
mistakes in the PHP languages, good luck to them :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75228 — Andrey Andreev — 2014-07-03T12:17:53+00:00

URL: https://externals.io/message/75209#75228 · In reply to: #75223

Hi,


> As
> to the "practical" implications that Andrey Andreeve mentioned in his reply.
>
> I shall not reply to that message, but if you insist on arguing that
> semantics are irrelevant to any degree, you are basically arguing that there
> is a good reason to make language harder to understand, read and write
> because of some other reason that has nothing to do with it (like how many
> constructs already exist).

This is exactly what I meant by "extreme". I've never said that
semantics are irrelevant, yet you're taking something that you don't
like about my opinion and you're twisting it into something completely
different. You can do "not_null" in any of the following ways:

    $var !== null
    ! is_null($var)
    isset($var)
    ! empty($var)

I said, in the context of this thread, that semantics alone can't
justify the existance of yet another way to achieve the same goal.
Quite frankly, the idea that a programmer, regardless of knowledge or
experience, wouldn't be able to easily understand any of the above 4
expressions is absurd.

Cheers,
Andrey.

---

## #75240 — Kris Craig — 2014-07-03T22:47:07+00:00

URL: https://externals.io/message/75209#75240 · In reply to: #75228

>
>     $var !== null
>     ! is_null($var)


Is there any *practical* difference between these two?  I mean, aside from
performance?  I still don't get why we need `is_null()` at all if the exact
same thing can be accomplished-- but with better performance-- with ===
NULL.

--Kris

---

## #75242 — Andrey Andreev — 2014-07-04T07:18:34+00:00

URL: https://externals.io/message/75209#75242 · In reply to: #75240

HI,

Not any that I'm aware of, and I personally have never used `is_null()`.
I share your opinion that we don't really need `is_null()`, but with BC
in mind, I don't think it would get removed.

Cheers,
Andrey.


> > […]
>
>
> Is there any *practical* difference between these two?  I mean, aside from
> performance?  I still don't get why we need `is_null()` at all if the exact
> same thing can be accomplished-- but with better performance-- with ===
> NULL.
>
> --Kris

---

## #75243 — Stas Malyshev — 2014-07-04T07:26:10+00:00

URL: https://externals.io/message/75209#75243 · In reply to: #75242

Hi!

> Not any that I'm aware of, and I personally have never used `is_null()`.
> I share your opinion that we don't really need `is_null()`, but with BC
> in mind, I don't think it would get removed.

There's nothing to remove. Every type has is_* function, including null
type. If `is_null()` is offensive to somebody for some reason, that person
is free to not use it.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

## #75244 — Kris Craig — 2014-07-04T07:43:25+00:00

URL: https://externals.io/message/75209#75244 · In reply to: #75243

On Fri, Jul 4, 2014 at 12:26 AM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > […]
>
> There's nothing to remove. Every type has is_* function, including null
> type. If `is_null()` is offensive to somebody for some reason, that person
> is free to not use it.
>

I'm not offended by it and I get that it was initially created for the sake
of having an is_* function for each type.  I'm just trying to understand
why it's *still* there and why it's not a language construct.  It serves no
unique purpose and has a negative performance impact.

What would be wrong with changing it from a function to a language
construct like isset() and empty()?  If `is_null()` were the equivalent of
!isset( $var ) || $var === NULL, it would make a hell of a lot more sense
than what's there now.

--Kris

---

## #75245 — Mats Lindh — 2014-07-04T07:57:38+00:00

URL: https://externals.io/message/75209#75245 · In reply to: #75244

> What would be wrong with changing it from a function to a language
> construct like isset() and empty()?  If `is_null()` were the equivalent of
> !isset( $var ) || $var === NULL, it would make a hell of a lot more sense
> than what's there now.
>

So your suggestion is to make it _exactly_ like isset?

Remember that language constructs are, in general, a cludge. They appear to
be functions, but you can't use them in places where you'd use a function,
such as validation callbacks. If you make is_null a language construct,
validate($foo, 'is_null') would not work as people assume.

There is no utility gained from removing or changing is_null. It
complements the other is_* functions that check for a specific type, and
having more than one way to achieve something is not always a bad idea.

Let this one rest.

--mats

---

## #75246 — Peter Cowburn — 2014-07-04T08:00:31+00:00

URL: https://externals.io/message/75209#75246 · In reply to: #75244

> On Fri, Jul 4, 2014 at 12:26 AM, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
>
> > […]
>
> I'm not offended by it and I get that it was initially created for the sake
> of having an is_* function for each type.  I'm just trying to understand
> why it's *still* there and why it's not a language construct.  It serves no
> unique purpose and has a negative performance impact.
>
> What would be wrong with changing it from a function to a language
> construct like isset() and empty()?  If `is_null()` were the equivalent of
> !isset( $var ) || $var === NULL, it would make a hell of a lot more sense
> than what's there now.
>

I don't use it often, and there are certainly other ways to achieve the
same result, but I have been known to employ the function as a callback
(e.g. to `array_filter()`) on occasion.  I'm not saying there's solid reason
to keep it around, just giving one example of a) where I've made use of it
before, and b) where changing it to a language construct would be
counter-productive.

Can we move on to frying bigger fish?!


> --Kris

---

## #75247 — Kris Craig — 2014-07-04T09:08:26+00:00

URL: https://externals.io/message/75209#75247 · In reply to: #75245

> 
>
> > […]
>
> So your suggestion is to make it _exactly_ like isset?
>

No, isset() returns `TRUE` if a variable exists and is not NULL.  So
technically, my suggestion is to make it exactly the opposite of isset().
 But now that I think of it, having `is_null()` essentially duplicate
!isset() instead of duplicating === `NULL` wouldn't make it any more
worthwhile.

I guess I wouldn't object so much if the performance loss could be
mitigated somehow.  I don't mind having questionable aliases floating
around for convenience (like with what Peter mentioned regarding
callbacks), so long as they don't introduce a drag on performance.  It's
that completely unnecessary perf hit that troubles me.

--Kris

---

## #75248 — Robert Stoll — 2014-07-04T12:34:17+00:00

URL: https://externals.io/message/75209#75248 · In reply to: #75209

Hey,

> -----Original Message-----
> From: Xen [mailto:xen@dds.nl]
> Sent: Thursday, July 03, 2014 11:40 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] not_null function
> 
> Heya,
> 
> I was just wondering about something.
> 
> It seems way more natural and flowing to have and use a "not_null"
> function in addition to some "is_null" that currently exists.
> 
> The reason is that most of the time you are not checking null condition,
> you are really checking the non-null condition.
> 
> But a line like "if (!is_null($a))" feels like there are two verbs in it.
> 
> It is like you are saying "if $a is not is null".
> 
> It is different for the "empty" function because there is no "is_" prefix
> in it. So "if (!empty($a)) feels completely sane.
> 
> So generally I will *want* to test a null condition but I just hope my
> variable won't contain anything that evaluates to false and just test "if
> ($a)".
> 
> If there was a not_null() I would use that instead, because "if
> (not_null($a))" only contains one "verb" instead of two.
> 
> And I would define that helper function myself, but I don't want to write
> code that another person would not be able to run just because not_null is
> not defined in his library.
> 
> --------
> In general I believe this is rather a problematic feature of most
> languages.
> 
> The "if" statement implies a verb, but many functions and methods also
> contain a verb in their name.
> 
> This seems to be only the case for the "is" verb. I know in my language
> (Dutch) the "to be" verb (zijn) is treated differently from all other
> verbs when it comes to the adverb/adjective difference.
> 
> When you state "I am good" the adjective is used, but "I work good" should
> be "I work well". The adjective applies to the subject "I" but the adverb
> applies to the verb "work". I guess there are all sorts of mixtures, "I am
> well" is also used. But I think it is improper.
> 
> Thus, "if (has_members())" feels natural because it uses a different verb
> replacing the default "is".
> 
> But "if (is_null())" feels odd because "if (null())" would say the same
> thing only more concise and more natural as far as if statements go, or at
> least it seems that way to me.
> 
> Personally I try to avoid those "is_something" functions whenever I can.
> It is not so much an issue if it is some rarely used library call.
> 
> Like WordPress has functions like "is_single()" which returns a boolean
> indicating whether the currently loaded page is a single post display.
> 
> But notice that "if (single())" would give very little information as to
> what you were actually testing. There is no parameter, and just "single"
> would be so general that it would completely obfuscate the fact that it
> had to do with WordPress. It would have to become "page_is_single()"
> although "page" is (improperly) dedicated to a special type of post that
> sits outside of the regular post structure. They ought to rename it to
> "staticpage" or "static". "page_is_single" and "page_is_home" and
> "page_is_category" would be more descriptive.
> 
> But in any case, this language incongruency is most annoying with core
> functions you have to use all the time, or would be using all the time if
> they were okay.
> 
> So my suggestion would be to consider introducing at least "not_null".
> "isset" seems to be a different category, if only because the verb is not
> visually separated from the condition.
> 
> So "if (isnull($a))" would again be more natural. But because the verb is
> visually separated using the underscore, you get two verbs in your mind.
> Perhaps creating an "isnull" alias and then deprecating the "is_null"
> function would be best.
> 
> Regards,
> 
> Bart Schouten
> 
> ps. please "reply all" for I am not subscribed as of yet.
> 
> --
> 
> 

[Robert Stoll] 

I really like how ruby tackles this problem with the syntactic sugar "unless" which basically is a substitute for "if( !() )".
Maybe we could consider to introduce it in PHP next? It is very natural to read "unless(is_null($x))" an much nicer than "if(!is_null($x)" IMO. And it would not only solve your issue with is_null but is_Xy functions/methods in general.

Cheers,
Robert

---

## #75252 — xen@dds.nl — 2014-07-04T20:27:27+00:00

URL: https://externals.io/message/75209#75252 · In reply to: #75248

Op Fri, 04 Jul 2014 14:34:17 +0200 schreef Robert Stoll <php@tutteli.ch>:

> [Robert Stoll]
>
> I really like how ruby tackles this problem with the syntactic sugar  
> "unless" which basically is a substitute for "if( !() )".
> Maybe we could consider to introduce it in PHP next? It is very natural  
> to read "unless(is_null($x))" an much nicer than "if(!is_null($x)" IMO.  
> And it would not only solve your issue with is_null but is_Xy  
> functions/methods in general.

I think that is just flawless. Thank you SO much for suggesting this.

I don't know how Ruby then handles the alternative condition, but I would
imagine that "unless () {} otherwise {}" would be very sweet.

This is just marvelous. It does indeed solve all the problems. You, we,
won't need any not_null. We won't need any not_anything. With this
addition everything I have said here and more of what I wanted to say,
given enough attention, because I didn't want to finish with something
half-baked, and I really wanted to study this thing more before I made a
final writeup, - everything I have said is voided. Basically. Not
entirely. But almost, yes.

Because you still have the cross-contamination between isset and is_null.
People wrongly use "isset" to test for "is set and is not null". So you
would have to keep is_null as meaning "if it is not set or (if it is set)
it is null".

"unless (is_null())" would then mean "unless (!isset || is_null)" but it
would definitely be better than abusing isset for this.

I really could never have come up with something like this lol. I guess my
mind is too closed from all those years of only using "ifs". This just
breaks everything open. Amazing.

So THANK YOU :D. I still want to do a bigger writeup, but it will take
some time, because I really want to "come to the ice with good irons on"
as they say in Dutch.

So in any case, enjoy the summer (if you are in the Northern hemisphere)
and let's talk again some time.

Bart Schouten, Netherlands.

---

## #75253 — Levi Morrison — 2014-07-04T21:26:44+00:00

URL: https://externals.io/message/75209#75253 · In reply to: #75252

> Op Fri, 04 Jul 2014 14:34:17 +0200 schreef Robert Stoll <php@tutteli.ch>:
>
>
> > […]
>
>
> I think that is just flawless. Thank you SO much for suggesting this.

For completeness, it is available in Perl and I believe Perl had it
first; not completely sure though.


> Because you still have the cross-contamination between isset and is_null.
> People wrongly use "isset" to test for "is set and is not null". So you
> would have to keep is_null as meaning "if it is not set or (if it is set)
> it is null".
>
> "unless (is_null())" would then mean "unless (!isset || is_null)" but it
> would definitely be better than abusing isset for this.

I don't think changing isset would be beneficial, sadly. I wish it
only checked that a variable exists and didn't do the not null check
but it's used very, very widely.

---

Next page: https://externals.io/message/75209.md?page=2