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:[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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
