>
>
> 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 how
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
