Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <87728790.20050613214458@ionzoft.com>
References: <5.1.0.14.2.20050603203711.028e9140@localhost> <200506051859.53976.magnus@php.net> <6E.27.21296.C90E7A24@pb1.pair.com> <38.CE.21296.BFD78A24@pb1.pair.com>  <43.34.20931.17BEDA24@pb1.pair.com> <1118701987.27553.6.camel@blobule.suds> <53F92510-14F5-4E4E-939F-8FC382A7B925@botimer.net> <87728790.20050613214458@ionzoft.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <F2AF8688-6697-4822-A577-68E2F97546BC@botimer.net>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Tue, 14 Jun 2005 00:19:46 -0400
To: Jason Garber <jason@ionzoft.com>
Subject: Re: [PHP-DEV] PHP 5.1
From: noah@botimer.net (Noah Botimer)

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.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
>>>
>>>
>>>
>>>
>>>
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>