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

2012/5/3 Lester Caine <lester@lsces.co.uk>:

Use case: // Function definition: function getFriends() { // SQL SELECT or Fetching from XML or Fetching from LDAP or ... return $resultsAsArray; } // Looping on results: foreach ( getFriends() as $friend ) { echo $friend["name"], "\n"; } // Case where the results are actually not iterated: $amIAssocial = empty( getFriends() ); 1. It it not wrong to return "nothing", like empty sets (empty arrays), it is a valid case. 2. Returning "false" in the case there is no "results" would be a bad idea: not only you would have to put a condition in the function definition, but you would also require all iterations (e.g. foreach) to be encapsulated in a condition statement to prevent looping on "false".

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.