Re: not_null function
| From: | Peter Cowburn | Date: | Fri, 04 Jul 2014 08:00:31 +0000 |
| Subject: | Re: not_null function | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75246@lists.php.net to get a copy of this message | ||
On 4 July 2014 08:43, Kris Craig <kris.craig@gmail.com> wrote:
> 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
>