November 05, 2007
Bruce Adams wrote:
>BCS Wrote:
>>Reply to Bruce,
>>>BCS Wrote:
>>>
> 
> Right. So what you really want is something that runs when the scope ends naturally but not on a break.
> 
> for(int i=5;i>0;i--)
> {
>   ...
>   break;
> }
> if (i<=0) ThisNeverRuns();
>  
> 

that has the same behavior but duplicates the end condition check. This can be both a performance hit and can be really bad when the condition changes or if it has side effects.

> 
>>>scope(skip):  - saves you one conditional - not very useful
>>>
>>>if (!cond)
>>>DoIfCondNeverPasses();
>>>else do
>>>{
>>>...
>>>}
>>>while(cond);
>>>
>>
>>mine looks better (IMHO)
>>
> 
> It doesn't justify a syntax change (IMHO)
>  

IIRC scope is totally redundant to begin with, your counter argument apply to it's existing functionality but people still like it.

> 
>>>scope(break): - saves you a function call or two.
>>>
>>>while(cond)
>>>{
>>>...
>>>if (cond2) DoOnBreak(); break;
>>>...
>>>if (cond3) DoOnBreak(); break;
>>>...
>>>}
>>
>>you prove half of my point and don't address the other half
>>
> 
> What was the other half again?
>  
> 

Below

>>while(cond)
>>{
>>...
>>if (cond2)
>>  DoOnBreak();
>>break;
>>...   // this never runs
>>if (cond3)
>>  DoOnBreak();
>>
>>break;
>>...
>>}
>>
>>If you didn't get it correct in this case, what are the chances of making an error in a more complicated case
>>
> 
> Harsh.  I was writing at 2am or thereabouts. Also you missed a semi-colon in 
your for loop above does that render anything moot?
> Personally I try to keep the body of a loop and in particular the control flow simple. I try to avoid breaks and put anything too large separate functions where possible.
> 

Have you ever written real code at 2AM? I'd like to have a language that  helps me not make mistakes. We're all human.

> 
>>The other part is that it is very easy to forget to add the DoOnBreak to one of the breaks (you try finding them all in old code) or adding it to every new one (Now what needs to be done on break this time).
>>
>>Also, it will work with mixin(string) when you can't get to the string.
>>
> 
> That might be a more valid use. Care to post an example? I think we have to be careful with mixin's. They could easily be as abused as macros. There's no reason you couldn't write with a style that has an exit condition specified in the mixin. I don't like the idea of having a mixin with a break or return hidden in it (that goes beyond the scope of the mixin itself). That could make it very hard to follow the control flow.
>  
> 

agreed, mixin can make for some nasty code.


> 
>>In all these cases the compiler can trivially implement them with copy/paste and by rearranging jumps.
>>
> 
> I'm more worried about the programmer having to maintain code using bizarre constructs. The compiler can be clever out of sight.
> 

It's not about the compiler being clever, it about the code having fewer internal dependencies.

> Regards,
> 
> Bruce.

I like the scope solution because it states stuff where it makes a difference, not where it needs to be done. Also it states stuff in a way that make the intention of the code more clear. "do this then" rather than "when that, do this" or even worse "do this now" in several places.

I'll concede it is a style issue.
1 2 3
Next ›   Last »