Re: ifsetor(), goto, 5.x, my two cents

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