Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <002c01c5f5bf$f55e8c20$7d051fac@stumpy>
To: "\"Dmitry Stogov\"" <dmitry@zend.com>
Cc: <internals@lists.php.net>
References: <2B.E1.14828.4130D834@pb1.pair.com> <000001c5f584$77823f80$e902a8c0@thinkpad>
Date: Wed, 30 Nov 2005 07:08:23 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Labeled Break (nothing at all whatsoever to do with GOTO)
From: pollita@php.net ("Sara Golemon")

> This "break LABEL" construct does exactly the same as "break NUM",
>
> May be I missed something? I didn't look into patch deep.
>
Your take is spot-on.  This isn't an extension of functionality, just a 
"numbered breaks with a name" which is something I've heard requested from 
several corners (including @zend.com) as a "wouldn't it be nice..."

> Also I don't like syntax for loops that you suggested.
> I prefer "LABEL: while(1) {...}" instead of while LABEL (1) {...}".
>
I agree that the positioning of the label has an inherent ugliness to it. 
I avoided "LABEL: while (1) { }" however, in order to avoid conflicting with 
and complicating the GOTO discussion.  Since (if goto was added as well) 
this syntax could create an ambiguity in what the label means.

Since you'd like the label to be moved out of zend_brk_cont_element, then 
perhaps we can allow this syntax to pull double duty...
LABEL: whlie(1) {
  break LABEL; <-- el->brk
  continue LABEL;  <-- el->cont
  goto LABEL;  <-- opline->u.opline_num
  break OTHERLABEL; <-- error
  continue OTHERLABEL; <-- error
  goto OTHERLABEL; <-- opline->u.opline_num
}
OTHERLABEL:
nonBreakContainerStatement();

> This construct has logic and make sense, but I am not sure that we should
> incrise complication of PHP compiler without any serious benefits.
> Readability is the only one benefit of this patch.
>
So the question is:  How serious is the gain in readability/maintainability?

-Sara