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
