Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16572
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 08 Jun 2005 19:37:03 -0600
In-reply-to: <ECDCEE8D-2160-46B7-BF84-AB163E477707@botimer.net>
To: internals@lists.php.net
Cc: Noah Botimer <noah@botimer.net>
Message-ID: <200506081937.03264.benjcarson@digitaljunkies.ca>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <ECDCEE8D-2160-46B7-BF84-AB163E477707@botimer.net>
User-Agent: KMail/1.7.2
Subject: Re: [PHP-DEV] ifsetor(), goto, 5.x, my two cents
From: benjcarson@digitaljunkies.ca (Benj Carson)

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