Re: not_null function
| From: | Kris Craig | Date: | Thu, 03 Jul 2014 11:23:26 +0000 |
| Subject: | Re: not_null function | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75216@lists.php.net to get a copy of this message | ||
On Thu, Jul 3, 2014 at 3:24 AM, Tjerk Meesters <tjerk.meesters@gmail.com>
wrote:
> Hi Bart,
>
>
> On Thu, Jul 3, 2014 at 5:40 PM, Xen <xen@dds.nl> wrote:
>
> > 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.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
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