Re: not_null function

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()“³Æ‘ñXŠ >> ÑwkØä1@ >> 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