Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSwCp98MFx3FO8A7RJZvEeKncof4S1WCznhMTtFcZXPc9Q@mail.gmail.com>
References: <alpine.LNX.0.999.1407031108350.526@swan.dds.nl>
	<CAHMUw2HQPSqY8DvfKigHFc7AJcPU6bwa4hgmpN5tsh8fMzh+6Q@mail.gmail.com>
	<CAKOpQSwCp98MFx3FO8A7RJZvEeKncof4S1WCznhMTtFcZXPc9Q@mail.gmail.com>
Date: Thu, 3 Jul 2014 04:25:20 -0700
Message-ID: <CAKOpQSxuKD5Y8yzZig-T8oM6=E-jk+3PR00HqOkZrSR_cWfYag@mail.gmail.com>
To: Tjerk Meesters <tjerk.meesters@gmail.com>
Cc: Xen <xen@dds.nl>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3a81a095625404fd48435a
Subject: Re: [PHP-DEV] not_null function
From: kris.craig@gmail.com (Kris Craig)

--047d7b3a81a095625404fd48435a
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 3, 2014 at 4:23 AM, Kris Craig <kris.craig@gmail.com> wrote:

>
>
>
> 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
>
>
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

--047d7b3a81a095625404fd48435a--