not_null function - Externals

10 years ago by xen@dds.nl — view source

unread

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.

10 years ago by Tjerk Meesters — view source

unread

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

10 years ago by xen@dds.nl — view source

unread

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.

10 years ago by Kris Craig — view source

unread

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

10 years ago by Kris Craig — view source

unread

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

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

10 years ago by xen@dds.nl — view source

unread

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.

10 years ago by Lazare Inepologlou — view source

unread

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

10 years ago by xen@dds.nl — view source

unread

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.

10 years ago by Andrey Andreev — view source

unread

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.

10 years ago by Pierre Joye — view source

unread

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

10 years ago by xen@dds.nl — view source

unread

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.

10 years ago by Tjerk Meesters — view source

unread

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?

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

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.

--

--

Tjerk

10 years ago by johannes@schlueters.de — view source

unread

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.

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

10 years ago by Pierre Joye — view source

unread

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

10 years ago by Andrey Andreev — view source

unread

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.

10 years ago by Kris Craig — view source

unread

$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

10 years ago by Andrey Andreev — view source

unread

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.

$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

10 years ago by Stas Malyshev — view source

unread

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/

10 years ago by Kris Craig — view source

unread

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

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.

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

10 years ago by Mats Lindh — view source

unread

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

10 years ago by Kris Craig — view source

unread

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?

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

10 years ago by Peter Cowburn — view source

unread

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

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.

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

10 years ago by Robert Stoll — view source

unread

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

10 years ago by xen@dds.nl — view source

unread

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.

10 years ago by Levi Morrison — view source

unread

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.

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.

10 years ago by xen@dds.nl — view source

unread

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

Okay, I never used Perl.

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.

As long as people don't have to use isset anymore to check for a not-null,
perhaps over time this widespreadedness would become less.

As soon as you can use "unless (is_null())" to check whether a variable
exists and is not null, the need for using isset for this should greatly
diminish...

Just my perspective. I don't know what other people think, the boogieman
of this list seems to not want to discuss anything related to this, so I
don't know.

I mean for me it means having to rethink my thinking, i.e. to get used to
this new statement. But it would probably become very natural?

I would imagine a lot of people becoming enthusiastic about an "unless"
statement. It is also a sexy thing to introduce and it doesn't require any
changes to existing code.

Again, just my perspective. Curious what other people really think at this
point.

Regards, Bart

10 years ago by Kris Craig — view source

unread

For completeness, it is available in Perl and I believe Perl had it

first; not completely sure though.

Okay, I never used Perl.

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.

As long as people don't have to use isset anymore to check for a not-null,
perhaps over time this widespreadedness would become less.

As soon as you can use "unless (is_null())" to check whether a variable
exists and is not null, the need for using isset for this should greatly
diminish...

Just my perspective. I don't know what other people think, the boogieman
of this list seems to not want to discuss anything related to this, so I
don't know.

I mean for me it means having to rethink my thinking, i.e. to get used to
this new statement. But it would probably become very natural?

I would imagine a lot of people becoming enthusiastic about an "unless"
statement. It is also a sexy thing to introduce and it doesn't require any
changes to existing code.

Again, just my perspective. Curious what other people really think at this
point.

Regards, Bart

--

I'm not much into Perl or Ruby, either, but I agree that an unless keyword
would be a very nice thing to have. However, I'm still not sure how that
would solve the isset problem. If the variable doesn't exist, are you
saying that encapsulating it within the unless arg would prevent an
undefined variable notice from being thrown? If so, could someone
elaborate on why that is? And if not, then while I do agree it's a good
idea on its own merits, I don't think it solves the issue we're mulling
over here.

Currently, this is what's available for checking a variable's status
without throwing any errors:

Variable exists and !== NULL: isset( $var )
Variable === NULL or doesn't exist: !isset( $var )
Variable == NULL or doesn't exist: empty( $var )
Variable exists and != NULL: !empty( $var )
Variable exists (including NULL): ????
Variable exists and === NULL: ????

It's those last two cases that we currently don't have any streamlined
approach for. If a variable is NULL and you use isset() on it, the return
will be FALSE. So if you were to do something like isset( $var ) && $var
=== NULL, that statement will always return FALSE, even you set the
variable with $var = NULL beforehand. You'll get the same problem using
empty(). In other words, as far as I can tell, there's currently no way to
tell if a variable is set and NULL (or just set with any value including
NULL) in PHP.

The closest thing I could find that accomplishes this is property_exists().
That function will return TRUE even on NULL values. But as I understand
it, that function only works on properties; i.e. variables that are a part
of a class. There doesn't seem to be any option for doing this with
procedural variables. We know that setting a variable to NULL in PHP is
not the same as unsetting it because referring to it later won't throw an
undefined notice, but aside from catching that notice itself, there doesn't
seem to be any way to accomplish this. Am I missing something? I realize
it's an edge case, but it still needs to be covered.

--Kris

10 years ago by Tjerk Meesters — view source

unread

For completeness, it is available in Perl and I believe Perl had it

first; not completely sure though.

Okay, I never used Perl.

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.

As long as people don't have to use isset anymore to check for a
not-null,
perhaps over time this widespreadedness would become less.

As soon as you can use "unless (is_null())" to check whether a variable
exists and is not null, the need for using isset for this should greatly
diminish...

Just my perspective. I don't know what other people think, the boogieman
of this list seems to not want to discuss anything related to this, so I
don't know.

I mean for me it means having to rethink my thinking, i.e. to get used to
this new statement. But it would probably become very natural?

I would imagine a lot of people becoming enthusiastic about an "unless"
statement. It is also a sexy thing to introduce and it doesn't require
any
changes to existing code.

Again, just my perspective. Curious what other people really think at
this
point.

Regards, Bart

--

I'm not much into Perl or Ruby, either, but I agree that an unless keyword
would be a very nice thing to have. However, I'm still not sure how that
would solve the isset problem. If the variable doesn't exist, are you
saying that encapsulating it within the unless arg would prevent an
undefined variable notice from being thrown? If so, could someone
elaborate on why that is? And if not, then while I do agree it's a good
idea on its own merits, I don't think it solves the issue we're mulling
over here.

Currently, this is what's available for checking a variable's status
without throwing any errors:

Variable exists and !== NULL: isset( $var )
Variable === NULL or doesn't exist: !isset( $var )
Variable == NULL or doesn't exist: empty( $var )
Variable exists and != NULL: !empty( $var )
Variable exists (including NULL): ????

Yep, nothing exists for that; we have a whole bunch of _exists()
functions, but not e.g. variable_exists() or even a dedicated exists
opcode.

Variable exists and === NULL: ????

That's simply @$var === null or @is_null($var) of course ;-)

It's those last two cases that we currently don't have any streamlined
approach for. If a variable is NULL and you use isset() on it, the return
will be FALSE. So if you were to do something like isset( $var ) && $var
=== NULL, that statement will always return FALSE, even you set the
variable with $var = NULL beforehand. You'll get the same problem using
empty(). In other words, as far as I can tell, there's currently no way to
tell if a variable is set and NULL (or just set with any value including
NULL) in PHP.

The closest thing I could find that accomplishes this is property_exists().
That function will return TRUE even on NULL values. But as I understand
it, that function only works on properties; i.e. variables that are a part
of a class. There doesn't seem to be any option for doing this with
procedural variables. We know that setting a variable to NULL in PHP is
not the same as unsetting it because referring to it later won't throw an
undefined notice, but aside from catching that notice itself, there doesn't
seem to be any way to accomplish this. Am I missing something? I realize
it's an edge case, but it still needs to be covered.

--Kris

--

Tjerk

10 years ago by Kris Craig — view source

unread

Currently, this is what's available for checking a variable's status
without throwing any errors:

Variable exists and !== NULL: isset( $var )
Variable === NULL or doesn't exist: !isset( $var )
Variable == NULL or doesn't exist: empty( $var )
Variable exists and != NULL: !empty( $var )
Variable exists (including NULL): ????

Yep, nothing exists for that; we have a whole bunch of _exists()
functions, but not e.g. variable_exists() or even a dedicated exists
opcode.

Variable exists and === NULL: ????

That's simply @$var === null or @is_null($var) of course ;-)

Is there any practical reason that you know of why 'exists' doesn't exist
(maybe there's some reason why it shouldn't)? Or is it just something that
never came up? If the latter, I wonder if there'd be any support for
changing that.

--Kris

10 years ago by Tjerk Meesters — view source

unread

On Sat, Jul 5, 2014 at 3:39 PM, Tjerk Meesters tjerk.meesters@gmail.com
wrote:

For completeness, it is available in Perl and I believe Perl had it

first; not completely sure though.

Okay, I never used Perl.

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.

As long as people don't have to use isset anymore to check for a
not-null,
perhaps over time this widespreadedness would become less.

As soon as you can use "unless (is_null())" to check whether a variable
exists and is not null, the need for using isset for this should greatly
diminish...

Just my perspective. I don't know what other people think, the boogieman
of this list seems to not want to discuss anything related to this, so I
don't know.

I mean for me it means having to rethink my thinking, i.e. to get used
to
this new statement. But it would probably become very natural?

I would imagine a lot of people becoming enthusiastic about an "unless"
statement. It is also a sexy thing to introduce and it doesn't require
any
changes to existing code.

Again, just my perspective. Curious what other people really think at
this
point.

Regards, Bart

--

I'm not much into Perl or Ruby, either, but I agree that an unless keyword
would be a very nice thing to have. However, I'm still not sure how that
would solve the isset problem. If the variable doesn't exist, are you
saying that encapsulating it within the unless arg would prevent an
undefined variable notice from being thrown? If so, could someone
elaborate on why that is? And if not, then while I do agree it's a good
idea on its own merits, I don't think it solves the issue we're mulling
over here.

Currently, this is what's available for checking a variable's status
without throwing any errors:

Variable exists and !== NULL: isset( $var )
Variable === NULL or doesn't exist: !isset( $var )
Variable == NULL or doesn't exist: empty( $var )
Variable exists and != NULL: !empty( $var )
Variable exists (including NULL): ????

Yep, nothing exists for that; we have a whole bunch of _exists()
functions, but not e.g. variable_exists() or even a dedicated exists
opcode.

Variable exists and === NULL: ????

That's simply @$var === null or @is_null($var) of course ;-)

Obviously spoke to soon ... what I've written there is basically an ugly
!isset($var).

Sorry for the extra noise.

It's those last two cases that we currently don't have any streamlined
approach for. If a variable is NULL and you use isset() on it, the return
will be FALSE. So if you were to do something like isset( $var ) && $var
=== NULL, that statement will always return FALSE, even you set the
variable with $var = NULL beforehand. You'll get the same problem using
empty(). In other words, as far as I can tell, there's currently no way
to
tell if a variable is set and NULL (or just set with any value including
NULL) in PHP.

The closest thing I could find that accomplishes this is
property_exists().
That function will return TRUE even on NULL values. But as I understand
it, that function only works on properties; i.e. variables that are a part
of a class. There doesn't seem to be any option for doing this with
procedural variables. We know that setting a variable to NULL in PHP is
not the same as unsetting it because referring to it later won't throw an
undefined notice, but aside from catching that notice itself, there
doesn't
seem to be any way to accomplish this. Am I missing something? I realize
it's an edge case, but it still needs to be covered.

--Kris

--

Tjerk

--

Tjerk

10 years ago by Pierre Joye — view source

unread

On Jul 5, 2014 9:43 AM, "Tjerk Meesters" <tjerk.me esters a gmail.com>
wrote:

Obviously spoke to soon ... what I've written there is basically an ugly
!isset($var).

Totally fail to see what is ugly with is set or the difference with
exists(). The latter, in the context of php (even more with phpng) makes
little sense.

Besides that, I am not sure what is the goal of this thread. Adding aliases
to copy cat <some language>?

10 years ago by Robert Stoll — view source

unread

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Saturday, July 05, 2014 10:06 AM
To: Tjerk Meesters; PHP internals
Subject: Re: [PHP-DEV] not_null function

On Jul 5, 2014 9:43 AM, "Tjerk Meesters" <tjerk.me esters a gmail.com>
wrote:

Obviously spoke to soon ... what I've written there is basically an ugly
!isset($var).

Totally fail to see what is ugly with is set or the difference with
exists(). The latter, in the context of php (even more with phpng) makes
little sense.

Besides that, I am not sure what is the goal of this thread. Adding aliases
to copy cat <some language>?

[Robert Stoll]
I really don't see what you have against copy cat <some language> if this language has actually solved a problem nicely (hence PHP could benefit from the idea).
And in my case I did not copy cat <some language> for <some random feature> but suggested something which would actually solve the problem at hand. And don't you think that should be the point of this discussion and not throwing in such questions which are merely deconstructive? (aren't you the guy who wrote those emails about giving good feedback via email... I found them interesting). But anyway, we really shouldn't discuss this point on the internal list, feel free to write to me in private.

10 years ago by Robert Stoll — view source

unread

-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Saturday, July 05, 2014 3:22 AM
To: Xen
Cc: Levi Morrison; internals
Subject: Re: [PHP-DEV] not_null function

For completeness, it is available in Perl and I believe Perl had it

first; not completely sure though.

Okay, I never used Perl.

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.

As long as people don't have to use isset anymore to check for a not-null,
perhaps over time this widespreadedness would become less.

As soon as you can use "unless (is_null())" to check whether a variable
exists and is not null, the need for using isset for this should greatly
diminish...

Just my perspective. I don't know what other people think, the boogieman
of this list seems to not want to discuss anything related to this, so I
don't know.

I mean for me it means having to rethink my thinking, i.e. to get used to
this new statement. But it would probably become very natural?

I would imagine a lot of people becoming enthusiastic about an "unless"
statement. It is also a sexy thing to introduce and it doesn't require any
changes to existing code.

Again, just my perspective. Curious what other people really think at this
point.

Regards, Bart

--

I'm not much into Perl or Ruby, either, but I agree that an unless keyword
would be a very nice thing to have. However, I'm still not sure how that
would solve the isset problem. If the variable doesn't exist, are you
saying that encapsulating it within the unless arg would prevent an
undefined variable notice from being thrown? If so, could someone
elaborate on why that is? And if not, then while I do agree it's a good
idea on its own merits, I don't think it solves the issue we're mulling
over here.

[Robert Stoll]
I suggested "unless" for the initial problem -> is_null does not exists. And it would only be a substitute for "if(!())"
Maybe it would be good idea to rename this thread since the topic has obviously changed by now.

Currently, this is what's available for checking a variable's status
without throwing any errors:

Variable exists and !== NULL: isset( $var )
Variable === NULL or doesn't exist: !isset( $var )
Variable == NULL or doesn't exist: empty( $var )
Variable exists and != NULL: !empty( $var )
Variable exists (including NULL): ????
Variable exists and === NULL: ????

It's those last two cases that we currently don't have any streamlined
approach for. If a variable is NULL and you use isset() on it, the return
will be FALSE. So if you were to do something like isset( $var ) && $var
=== NULL, that statement will always return FALSE, even you set the
variable with $var = NULL beforehand. You'll get the same problem using
empty(). In other words, as far as I can tell, there's currently no way to
tell if a variable is set and NULL (or just set with any value including
NULL) in PHP.

The closest thing I could find that accomplishes this is property_exists().
That function will return TRUE even on NULL values. But as I understand
it, that function only works on properties; i.e. variables that are a part
of a class. There doesn't seem to be any option for doing this with
procedural variables. We know that setting a variable to NULL in PHP is
not the same as unsetting it because referring to it later won't throw an
undefined notice, but aside from catching that notice itself, there doesn't
seem to be any way to accomplish this. Am I missing something? I realize
it's an edge case, but it still needs to be covered.

--Kris