Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20900
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <AB.AC.14828.A9FCD834@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 30 Nov 2005 17:13:55 +0100
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
References: <2B.E1.14828.4130D834@pb1.pair.com> <000001c5f584$77823f80$e902a8c0@thinkpad> <002c01c5f5bf$f55e8c20$7d051fac@stumpy>
In-Reply-To: <002c01c5f5bf$f55e8c20$7d051fac@stumpy>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Labeled Break (nothing at all whatsoever to do with
	GOTO)
From: bart@mediawave.nl (Bart de Boer)

Sounds good from a syntax perspective... :)


Sara Golemon wrote:
>> 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