Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSy=7+oxT5cqZ6iU17Lknexc1GW9B6uFUvO+BMyCG4uDKQ@mail.gmail.com>
References: <CAF+90c_N7fhQG_62pEgw_qm2LTDJf=ie0tN1PQVq4XNpMEYcmQ@mail.gmail.com>
	<CACwt+Jdn7hS8mszbEhhFtthL7hisG-SaXDahzKb9MhY2ZjOWLA@mail.gmail.com>
	<CABBJUpdAmkEzh9uek2McmdOCkVOWNuHo6kUsFYizGXbRVZ20Dw@mail.gmail.com>
	<CAEZPtU4VF7y3AJEYmPND-dGuWMrU2NCsXRTBF2p+czazrR33nQ@mail.gmail.com>
	<CAH-PCH5wtv07jLHE=_HzPAJHb-OivB=FdROcyh7dPJn8Tt1dVw@mail.gmail.com>
	<CAEZPtU7kv9X0K5kExXOg3nQBqLxXzGq5hc5DRq5dVj7cVdJ55w@mail.gmail.com>
	<396c1a02d4e7195f2b89e26ace2276a6.squirrel@www.l-i-e.com>
	<CAKOpQSy=7+oxT5cqZ6iU17Lknexc1GW9B6uFUvO+BMyCG4uDKQ@mail.gmail.com>
Date: Fri, 4 May 2012 22:27:07 +0200
Message-ID: <CAH-PCH44MT5B8-VoOoipdFHB6Fe5UNrbkmTG46WK9og69UYfJw@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: Richard Lynch <ceo@l-i-e.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10c86186e1ef04bf3bbebb
Subject: Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b10c86186e1ef04bf3bbebb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>
> I've been following the debate and I'm still a bit unclear as to what the
> benefit would be to allowing non-variables in isset().  I mean, as was
> stated earlier, expressions are neither "set" nor "unset".  Furthermore, =
if
> you were to assign a variable to any valid expression (empty or otherwise=
),
> it would be considered "set".  Therefore, through simple deductive logic,
> would an expression passed to isset() not, by definition, *always* return
> TRUE if the expression itself is syntactically valid?


yeah, this wouldn't be much to think about if isset in php wouldn't handle
null values as not set.
and as I mentioned expressions can return null, so it isn't true that any
expression given to isset would always result in true.
but I think we were talked this over already, so not much point repeating
the same arguments over and over again.

to summarize, the following cons were brought up against allowing
expressions for isset :


   - if you pass an undefined constant to isset, you will get unexpected
   result as isset will raise a notice and can return unexpected result as =
the
   constant is casted to string before being passed to isset(btw. this is h=
ow
   expressions work everywhere else, so it isn't a real surprise, but it is=
 a
   change to the current behavior).
      - this is a valid concern, but the same problem applies to empty too,
      so it is a general problem with the current patch/rfc. I think
it would be
      nice mentioning this in the rfc, as this could/will cause a few
wtf moments
      for some people.
   - isset(CONST) could be seen as defined("CONST") but they are returning
   different results if CONS is defined with NULL or undefined.
      - this is a valid concern, and there is no good solution, for
      isset(CONST) we either go cosistent with isset or declared, but can't=
 do
      both at the same time.
   - semantically empty can make sense for expressions, isset doesn't:
      - yep, the only thing that makes this a little less clear/obvious is
      the fact that isset in php also checks for value, not only the
"existence"
      of the variable.
   - following the previous point, there are much more fluent use-cases for
   empty(expression) than for isset(expression)
      - this is true, for null check you should use comparing the value,
      for other cases empty could be much more useful, only the isset(CONST=
)
      could be useful, but I mentioned the problems with that above.

after discussing this and thinking it over a few times, I decided that I
will drop my case about supporting both empty and isset.
I think that keeping the argument handling for isset and empty in sync
doesn't worth the possible gotchas.
and I now a little less sure about suporting this change for empty(), given
how much do we emphasized over the years that empty won't trigger any
warning about the non-existent variables.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b10c86186e1ef04bf3bbebb--