On June 8, 2005 04:20 pm, Noah Botimer wrote: > > 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). >
Not that my opinion counts for anything--I'm just a lowly user, though I do have a T-shirt that claims I'm a 'PHP 5 Pioneer'--but I could not agree with you more on both counts. Many PHP developers are also SQL developers, so I think COALESCE() would be an excellent implementation of the idea behind ifsetor() with a name that, as you mention, has at least some overlap with concepts that should be familiar to many PHP developers. I believe this name was also floated the first time ifsetor() was introduced here. > 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. I've also wished at times that PHP had goto, and I think it would be a useful addition to the language. There are times when error handling *within* a function would be better served with a simple goto (or named break) than with an exception (e.g. if there is no need for an error to bubble up outside of a function, but the function still needs to clean up after itself). While PHP may 'not be the right language' for parsers, adding goto could perhaps change that. PHP's text handling is superb, but there are times when PCRE just won't cut it and a state machine is needed. Why avoid new territory and curtail the potential usefulness of the language? No need to make parsing the primary focus, but in the same way that the cli sapi was added with 4.3 in order to expand the usage of PHP outside of web environments, goto could further that goal. If the concern regarding goto is the potential for spaghetti, then I think that can be addressed with solid documentation. If big fat warnings are prominently displayed alongside good examples of proper usage, then most users will get the idea. Plus, given the length of the debate here on internals, I would imagine that there will be a generous helping of user comments to support proper usage idioms as well. Again, just my two cents, but as a developer, both of these constructs would be very useful, and I think they will only increase the utility of PHP. Benj Carson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
