Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75216 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17111 invoked from network); 3 Jul 2014 11:23:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jul 2014 11:23:30 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.41 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.219.41 mail-oa0-f41.google.com Received: from [209.85.219.41] ([209.85.219.41:62713] helo=mail-oa0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3C/3F-47713-13D35B35 for ; Thu, 03 Jul 2014 07:23:29 -0400 Received: by mail-oa0-f41.google.com with SMTP id l6so60401oag.14 for ; Thu, 03 Jul 2014 04:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SVZrKgZDmaaRK5r1hWdyiMlPJRmLe6KNVbEVDtgKzpM=; b=r+LN2deqW7XjWXCyAQfo8Z/gqcC8RI9cg3IR3Po2cvayycR7fqqMeLuJznlUxNFJFI 7CbzZM9FaQeyChLJBHKKM1hZtps27x5EVP5lyJ0DMrvQNMEpfK+dBzuXBmfPyW7tDzb4 lrucEEpTNL3QoqXIJm63FHUErmlAn7uEZG+ZC5doW8M4UlGxFQhhUIuaJqPLW/mB76sf Y0UCsRyP/9l6Y2oyQnmS8c2HUCbVrYPzC3k0J0rSscBXTAUTY5+/07VLv5xq3L3s+hC8 AXH59U2iHRSq384haEExxjAmt83cz1VdACK9ddtaTZwHRoxx0Uzw1iTk1fe5wiww9omR kZwA== MIME-Version: 1.0 X-Received: by 10.182.228.163 with SMTP id sj3mr3925894obc.72.1404386606625; Thu, 03 Jul 2014 04:23:26 -0700 (PDT) Received: by 10.202.15.72 with HTTP; Thu, 3 Jul 2014 04:23:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jul 2014 04:23:26 -0700 Message-ID: To: Tjerk Meesters Cc: Xen , PHP Internals Content-Type: multipart/alternative; boundary=001a1136358ad0b80504fd483c61 Subject: Re: [PHP-DEV] not_null function From: kris.craig@gmail.com (Kris Craig) --001a1136358ad0b80504fd483c61 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 3, 2014 at 3:24 AM, Tjerk Meesters wrote: > Hi Bart, > > > On Thu, Jul 3, 2014 at 5:40 PM, Xen 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 --001a1136358ad0b80504fd483c61--