Re: not_null function

From: 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 >

« previous php.internals (#75246) next »