On Apr 11 14:14:40, Matt Wilson wrote:
> Something I've been doing for a long time is similar, but in my opinion a 
> much better practice.
> 
> function coalesce(&$val, $ifnull = false)
> {
>       return empty($val) ? $ifnull : $val;
> }
> 
> Add whatever restrictive logic you wish here, if empty() isn't good enough 
> for your purposes. 

The "problem" with such approach is that it will always end up defining
what $val is a reference of.

e.g.
$plop = coalesce($_GET['foo'], 'default']);

will end up leaving $_GET['foo'] assigned to null. That might be fine
with your usage, but having an operator for it would solve that
"problem".

Best,

> 
> $_GET['mightnotexist'] = coalesce($_GET['mightnotexist'], 'default');
> 
> Personally, I think if you're writing your code where a variable's existence 
> is ambiguous, you *should* be seeing notices.
> 
> On Apr 11, 2011, at 2:08 PM, Todd Ruth wrote:
> 
> > I'm not arguing whether the following code fragment is good
> > or bad (it's certainly less than ideal), but given the recent 
> > threads, I thought I'd show how I feel I've been encourage by 
> > php to code:
> > 
> > <?php
> > $x = array();
> > $y = 'something';
> > $temp =& $x[$y];
> > $temp++;
> > unset($temp);
> > ?>
> > 
> > I'm not sure where (if anywhere) that technique is documented
> > or even if it should be documented, but if you want to avoid
> > "Undefined index" notices, that's one of the more terse
> > approaches.  The relative brevity is more obvious when the
> > variable names are long and $temp is re-linked several times
> > before unsetting.  It's probably less clear than alternatives
> > unless you see it often.
> > 
> > Here is an application to the defaults for configurations thread:
> > 
> > <?php
> > $config = array();
> > $param = 'param1';
> > $temp =& $config[$param];
> > $temp = $temp ?: 'default';
> > unset($temp);
> > var_dump($config);
> > ?>
> > 
> > It isn't beautiful, but it avoids writing "$config[$param]"
> > more than once and it avoids the notices.
> > 
> > - Todd
> > 
> > 
> > -- 
> > 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

Reply via email to