Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16579
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <14.77.21296.CE1E7A24@pb1.pair.com>
References: <ECDCEE8D-2160-46B7-BF84-AB163E477707@botimer.net> <14.77.21296.CE1E7A24@pb1.pair.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <660DA80C-6E66-43C7-AB82-C276D9499F12@botimer.net>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Thu, 9 Jun 2005 09:26:16 -0400
To: Ron Korving <r.korving@xit.nl>
Subject: Re: [PHP-DEV] Re: ifsetor(), goto, 5.x, my two cents
From: noah@botimer.net (Noah Botimer)

Ron,

I was thinking about behavioral variants but left them out to keep my  
message shorter.  I haven't really thought of a clean way to use one  
named function to provide both types of functionality.  I was  
originally thinking of a constant parameter to indicate a "mode" but  
with the arbitrary length parameter list, it would have to come at  
the beginning, removing the possibility of optionality.  For  
understandability of code, it might make sense to implement two  
functions with the same behavior and similar names, but a different  
underlying call, so the intent is obvious upon reading.

Another possibility could be a variant where the first parameter  
would be a bool-returning callback and the return would be the first  
parameter that, when passed to that callback, returns a true (or non- 
zero/non-null) value.

As a final note, I would say that both isset() and !empty() are  
valuable and to neglect either one for syntactical sugar-coating  
might be an oversight.  Both are different and have applications to  
the concept, so both should supported in some fashion.

Thanks,
-Noah Botimer

On Jun 9, 2005, at 2:28 AM, Ron Korving wrote:

> I must say, I like the coalesce() idea a lot. It gives more  
> flexibility over
> ifsetor() which sounds to me like it only handles 1 variable that  
> is or
> isn't set. coalesce() would handle any number of variables.
>
> Here's something else to consider though:
>
> Would anybody be interested in a parameter for ifsetor() or coalesce 
> () that
> would use !empty() instead of isset() ? If coalesce() would become the
> function name of choice, you can't drop in a parameter to achieve  
> what I
> just said, so an alternative function would be better in that case  
> (or maybe
> it would be better in any case). I know I'd love to see some  
> variant like
> this. I use empty() a lot more than isset().
>
> Ron
>
>
> "Noah Botimer" <noah@botimer.net> wrote in message
> news:ECDCEE8D-2160-46B7-BF84-AB163E477707@botimer.net...
>
>> Hello all,
>>
>> Now that my PHP-DEV imap folder has cooled off a bit, I'd like to
>> chime in briefly on ifsetor() and goto.
>>
>> As far as ifsetor() goes, I like the concept.  I would, however,
>> suggest a specific behavior and a name change.  I do a lot of
>> database code and use things like ISNULL() and COALESCE() to
>> translate NULL values to 0's, placeholder strings, etc.  ISNULL()
>> typically provides a check of one value, and acts just as a ternary
>> operation:
>>
>> value = check ? check : alternative;
>>
>> while COALESCE() usually returns the first non-null parameter, or
>> NULL if all are parameters are NULL.
>>
>> Since PHP already supports arbitrary/optional parameters natively, I
>> think a single coalesce() function would be a very reasonable
>> extension that would behave in an understandable and desirable manner
>> (with a name that matches at least some common usage).
>>
>> As for goto, we may be fighting over nothing.  There is a lot of
>> abuse that may be done with goto, as has been illustrated but, with a
>> couple of sensible limitations, the horrific problems should be
>> averted.  It also seems to me that GOTO is far less often mentioned
>> to beginners as a means of flow control since line-numbered BASIC has
>> faded.  People who get into trouble with it will likely have a good
>> reason to be playing with fire.  I say: put it in, label it
>> dangerous, and let the developers decide if it's right for them.
>>
>> Thanks,
>> -Noah Botimer
>>
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>