Jason, you are absolutely right.. this is not about input filtering at all.
It's about replacing:
$x = (isset($ANY_var) ? $ANY_var : 'Default Value');
by
$x = ifsetor($ANY_var, 'Default Value');
So, Robert's solution is no real solution if you ask me. But again, it would
be best, if there was no ifsetor() at all, but that users would have the
power to create such a function themselves in the php code space. I have no
clue how though...
Perhaps with syntax like this or something:
function ifsetor(@&$var, $default)
{
return (isset($var)) ? $var : $default;
}
Though that seems kinda gross, as a syntax it could work ;)
Ron
"Jason Garber" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Noah,
>
> In general, the people who advocate writing this construct differently,
> are missing the point.
>
> ifsetor is NOT input filtering, it is not a complex, general purpose
> do-everything construct, it is a simple replacement for
>
> $x = (isset($ANY_var) ? $ANY_var : 'Default Value');
> $x = ifsetor($ANY_var, 'Default Value');
>
> It needs to be fast, and simple.
>
> Using @ is not acceptable, because it still entails a call to the
> custom error handler function.
>
> It ought to be able to handle any type.
>
> It will be a much-used, not-needed language construct that will
> speed up PHP, produce cleaner code, and encourage the adoption of
> E_ALL error reporting.
>
> Thanks.
>
> --
> Best regards,
> Jason mailto:[EMAIL PROTECTED]
>
> Monday, June 13, 2005, 8:23:17 PM, you wrote:
>
> NB> Rob,
>
> NB> I agree with you entirely. It's possible to write this code probably
> NB> a hundred different ways which, to me, also noting the number of
> NB> posts the topic has generated, indicates that it should be supported
> NB> in the language. A common convention for a common operation seems
> NB> like a sensible goal to me. As nice as it is to be able to roll your
> NB> own, code sharing is facilitated when we include de facto behaviors.
> NB> The single implementation close to the metal would also help with
> NB> speed and code verifiability.
>
> NB> Thanks,
> NB> -Noah
>
>
> NB> On Jun 13, 2005, at 6:33 PM, Robert Cummings wrote:
>
> >> On Mon, 2005-06-13 at 16:23, Ron Korving wrote:
> >>
> >>> If it were possible at all to make a function accept unset
> >>> variables without
> >>> generating a notice, I think ifsetor() shouldn't even be
> >>> implemented. People
> >>> could then have the freedom to create such functions themselves. But
> >>> unfortunately, it doesn't seem to be possible, unless you'd
> >>> suppress every
> >>> function call with a @, which I don't think is the way to go in
> >>> this case.
> >>>
> >>> So if it would be possible somehow to create your own isset()-like
> >>> functions
> >>> in PHP-code, I'd say implement something that would make that
> >>> possible, and
> >>> ingore the whole ifsetor() discussion from that moment on. People
> >>> would be
> >>> free to write whatever function they'd prefer.
> >>>
> >>
> >> Voila!
> >>
> >> function ifsetordefault( $array, $key, $default=null )
> >> {
> >> if( isset( $array[$key] ) )
> >> {
> >> return $array[$key];
> >> }
> >>
> >> return $default;
> >> }
> >>
> >> echo ifsetordefault( array( 1 => 'One', 2 => 'Two' ), 3, 'Three' );
> >>
> >> Or if you prefer:
> >>
> >> function ifsetpathordefault( $array, $path, $default=null, $sep='/' )
> >> {
> >> $pathBits = explode( $sep, $path );
> >>
> >> $nest = $array;
> >> foreach( $pathBits as $pathBit )
> >> {
> >> if( !isset( $nest[$pathBit] ) )
> >> {
> >> return $default;
> >> }
> >>
> >> $nest = $nest[$pathBit];
> >> }
> >>
> >> return $nest;
> >> }
> >>
> >> And yet, I'd still prefer an internal function to do this MUCH MUCH
> >> MUCH
> >> faster and then I'd also never need to run across the problem of
> >> naming
> >> collisions with other libraries that implement the same code :)
> >>
> >> Cheers,
> >> Rob.
> >> --
> >> ------------------------------------------------------------..
> >> | InterJinn Application Framework - http://www.interjinn.com |
> >> :------------------------------------------------------------:
> >> | An application and templating framework for PHP. Boasting |
> >> | a powerful, scalable system for accessing system services |
> >> | such as forms, properties, sessions, and caches. InterJinn |
> >> | also provides an extremely flexible architecture for |
> >> | creating re-usable components quickly and easily. |
> >> `------------------------------------------------------------'
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >>
> >>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
