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

From: Date: Tue, 01 May 2012 18:34:23 +0000
Subject: Re: [RFC] Allow non-variable arguments to empty() and isset()
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-60403@lists.php.net to get a copy of this message
On Tue, May 1, 2012 at 7:24 PM, Patrick ALLAERT <patrickallaert@php.net>wrote: > 2012/5/1 Ferenc Kovacs <tyra3l@gmail.com>: > > On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov <nikita.ppv@googlemail.com > >wrote: > > - 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. > > I wish that more wrong usages could blow up with parse errors way > before waiting for the incorrect line to be run. > One could argue that then you should pick a compiled language. > While there is some valid use cases for empty() I see none for > isset(), it must remain a targeted and specific construct IMHO. > I agree that there is less valid use-cases, but I feel that keeping the two method consistent about this is more important. > > > - maybe you think that isset doesn't really make sense with expressions, > > exact :) > > > but don't forget that this patch would also allow constants to be used > with > > empty/isset. > > That is not a very good think IMO. > > For the same reason: this patch would also allow writing: empty( false > ) or empty( null ) which are both clueless. > how is that different than for example writing is_null(null) ? > The fact that this patch would now allow syntactically doubtful things > doesn't mean they should be encouraged nor propagated to isset(). > we are already have that all over the place, I don't think that this particular patch will change anything about that. could you elaborate on this part a little bit? I mean you can write "stupid" code right now ($null=null;isset($null); instead of isset(null);), I can't see how would this patch worsen the situation. If anything, the silly code could be understood easier, as you wouldn't need to debug the value of the $null variable passed in. So I think that 1, we already too late to prevent that kind of code 2. even if we could, I don't think that the currently discussed patch would really encourage that kind of code 3, there are/could be valid use-cases for isset 4, isset and empty should work the same way in regards of the argument parsing. ofc. this is only my opinion, if I am the minority here, then it is fine too, I just wanted to explain what was the reasoning behind that discussion.. -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#60403) next »