Re: PHP 5.1
| From: | Noah Botimer | Date: | Tue, 14 Jun 2005 04:19:46 +0000 |
| Subject: | Re: PHP 5.1 | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-16648@lists.php.net to get a copy of this message | ||
Jason,
I realize that the initial focus is for a simple replacement for a ternary operation. However, I think it should be possible to make a more flexible construct to address more concerns without sacrificing much simplicity or performance, especially in an analogous case.
For example:
$x = coalesce($_POST['a_radio_group'], -1);
$x = coalesce($_POST['optional'], $settings['user_default'], $config['global_default']);
function greaterthan2($val) { return $val > 2; }
$x = ucoalesce("greaterthan2", $choice1, $choice2, $choice3);
With the addition of a form supporting a callback (set/unset/warning issues would apply), the user could determine what check he needed to perform, in the spirit of things like usort() and array_map().
Like you say, I may be missing the point, but I think a language-level construct to address more needs than fewer would be beneficial to performance AND de facto coding behaviors.
Thanks,
-Noah
On Jun 13, 2005, at 9:44 PM, Jason Garber wrote:
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.comMonday, 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:--PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpOn 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