not_null function View as Markdown

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.

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

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.

--

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

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.

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.

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.