Re: [RFC] Allow non-variable arguments to empty() and isset()

From: Date: Tue, 01 May 2012 16:43:46 +0000
Subject: Re: [RFC] Allow non-variable arguments to empty() and isset()
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-60398@lists.php.net to get a copy of this message
On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov <nikita.ppv@googlemail.com>wrote: > On Mon, Apr 30, 2012 at 9:50 AM, Patrick ALLAERT <patrickallaert@php.net> > wrote: > > Hi, > > > > 2012/4/12 Nikita Popov <nikita.ppv@googlemail.com>: > >> PS: I added isset() too, to address the consistency concerns mentioned > on IRC. > > > > I would have voted +1 if it didn't contain the isset() change. None of > > the examples used in the isset_with_expr.phpt test seems logic to me. > > > > Care to explain the consistency concerns here? > The concerns came from laruence, so maybe he could drop a comment here > :) Basically, empty() and isset() are very similar in their nature, so > changing only one of them might seem inconsistent. > > Personally I don't see much use in allowing expressions in isset(). > People being confused by empty(trim($_GET['foo'])) not working is > quite common, but I've never heard of somebody trying to use isset() > on a function call. The name already makes clear that it's intended > for use on variables. albeit I'm not laruence, but I also supported the idea to keep consistency across the allowed params of empty and isset. here is my reasoning: - both isset and empty are language constructs, which many people use almost interchangeability, changing one of them in a way that the same expression works with one of them, but blows up with a parse error seems wrong to me. - maybe you think that isset doesn't really make sense with expressions, but don't forget that this patch would also allow constants to be used with empty/isset, and imo isset(some_constant); would be useful and maybe more straightforward for the people new to the language. -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#60398) next »