Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACwt+JdgOCnnjsOodaH6OzT_5tS8PAB-0TB1dkC6GTTkUy2+Yg@mail.gmail.com>
References: <CAF+90c_N7fhQG_62pEgw_qm2LTDJf=ie0tN1PQVq4XNpMEYcmQ@mail.gmail.com>
	<CACwt+Jdn7hS8mszbEhhFtthL7hisG-SaXDahzKb9MhY2ZjOWLA@mail.gmail.com>
	<CAF+90c9nqRwiFETJk_2f_hEyncdVkb84m9_RGRXgvAvxqupVTw@mail.gmail.com>
	<CAH-PCH4vqVxtJbyrSThH0LSqND0+g1NgwJAw+m=-WwmgAAO3jw@mail.gmail.com>
	<CACwt+JdgOCnnjsOodaH6OzT_5tS8PAB-0TB1dkC6GTTkUy2+Yg@mail.gmail.com>
Date: Tue, 1 May 2012 20:34:23 +0200
Message-ID: <CAH-PCH4siE+Xgd3jOjRaFnTZHQXoa0QWZGBy6PbvZQztnXQpBw@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10cc31da571204befdd16a
Subject: Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b10cc31da571204befdd16a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 1, 2012 at 7:24 PM, Patrick ALLAERT <patrickallaert@php.net>wro=
te:

> 2012/5/1 Ferenc Kovacs <tyra3l@gmail.com>:
> > On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov <nikita.ppv@googlemail.co=
m
> >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 seem=
s
> > 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=3Dnull;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=
.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b10cc31da571204befdd16a--