Re: PHP 5.1

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:jason@ionzoft.com 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 >> >> >> >>