Re: what happened to that new isset() like language

Jason Garber wrote:

The original reason that I asked for this functionality was to make it significantly easier to work with E_ALL error reporting. When I say easier, I mean by reducing duplicate code. //This $foo = (integer) ifsetor($_POST['foo'], 0); //Instead of $foo = (integer) (isset($_POST['foo']) ? $_POST['foo'] : 0); It was also to be useful for accessing array elements that may or may not be there. I strongly agree with Ramsus that ?: is far to close to the ternary operator and would prove to be *highly* confusing to beginners.

I don't think it would be *highly* confusing to someone who has already used a ternary statement. If they haven't then even a ternary statement would be confusing. In either case I think good documentation would be important. I am still on the fence about the asymmetry in that one tests isset() while the other doesn't

Marcus made an excellent point about the 2 versions of the function: 1) $a = ifsetor($b) 2) $a = ifsetor($b, NULL)

See my response to Marcus' post

By the way, I'm not stuck on ifsetor() as a name, but a) the name should be short and clear b) the construct must be called with function like syntax Marc, I must ask, why are you so opposed to the function() syntax? There has been quite a few reasons stated against the operator syntax, but I haven't heard any reason why we should not go with the function() syntax?

I am interested in the new construct for the exact same reason, E_ALL development. I am intersted in the ?: operator because it looks alot simpler, especially if you want to chain them together: $user = $_SESSION['user] ?: $_POST['user'] ?: $local_user ?: NULL; I am not even sure if marcus' patch allowed you to nest multiple ifsetor() calls...either way, my main goal is simplicity. I am not just trying to be contentious, I am actually interested in a good solution. Marc