break (level);

Archive of the older Feature Request Forum Posts

Moderator: POL Developer

Locked
Bytehawk
Apprentice Poster
Posts: 56
Joined: Fri Feb 03, 2006 2:25 am

break (level);

Post by Bytehawk »

In some occasions it would be handy to have the break statement leaving not only the loop it currently is in, but also the loop wrapping the current one and the one wrapping that... uhm... i guest my english isn't sufficient to epxlain what I mean. This code hopefully better explains it:

Code: Select all

// I want to leave both for-endfor loops
// instead of having to do something like this:

program test(who)

  var spot:= array {};
  var x;
  var y;

  for (x:= (who.x - 5); x <= (who.x + 5); x:= x + 1)
    for (y:= (who.y - 5); y <= (who.y + 5); y:= y + 1)
      if (GetWorldHeight (x, y) == 0)
        spot:= array {x, y}; 
        break;               ---------+
      endif                           |
    endfor                            |
                                      |
    if (spot.size () > 0) <-----------+
      break;              ------------+
    endif                             |
  endfor                              |
                                      |
  SendSysMessage (who, "" + spot); <--+

endprogram



// I'd like to be able to do this:

program test(who)

  var spot:= array {};
  var x;
  var y;

  for (x:= (who.x - 5); x <= (who.x + 5); x:= x + 1)
    for (y:= (who.y - 5); y <= (who.y + 5); y:= y + 1)
      if (GetWorldHeight (x, y) == 0)
        spot:= array {x, y}; 
        break 2;             ---------+
      endif                           |
    endfor                            |
  endfor                              |
                                      |
  SendSysMessage (who, "" + spot); <--+

endprogram
One already can pass the name of a label as a parameter to the break statement, but the label this points to has to be definded before the break statement. It would be a lot more useful if labels could be defined in the code somewhere before or after the break statement. But since using absolute jumps (ore whatever is the correct term for it) isn't the smartes way to code, break <level>; would be way better.
User avatar
Austin
Former Developer
Posts: 621
Joined: Wed Jan 25, 2006 2:30 am

Post by Austin »

EScript Already has this.. uses labels.


You can see an example here:
http://svn.sourceforge.net/viewcvs.cgi/ ... c?view=log

Or another example:

Code: Select all

 
SOMELABEL: foreach iter in ( array ) 
               break SOMELABEL;
          endforeach
Bytehawk
Apprentice Poster
Posts: 56
Joined: Fri Feb 03, 2006 2:25 am

Post by Bytehawk »

Uhm, yes, but the label has to be definded in the script before the break. If you put it in the script somewhere after the break, ecompile gives you an error message. Wouldn't the example you posted produce an endless loop? (search the array, break to SOMELOOP, search the array again, break egain....) Am I getting this wrong again? :)
User avatar
Austin
Former Developer
Posts: 621
Joined: Wed Jan 25, 2006 2:30 am

Post by Austin »

'continue' means skip all remaining commands in the loop and move to the next point in it.

You could do something crazy like this

Code: Select all

ALPHA: foreach shin in ( igami )
     BRAVO: foreach muad in ( dib ) 
          CHARLIE: foreach aus in ( tin )
                   DELTA: foreach mad in ( man )
                    if ( mad.home == CALIFORNIA )
                         break BRAVO;
                    endif
          endforeach
     endforeach
endforeach
This would cause BRAVO, CHARLIE and DELTA to stop and move onto the next iter in ALPHA.

If you did continue BRAVO; you would stop looping CHARLIE and DELTA and move onto the next iteration in BRAVO.
Lagoon
Grandmaster Poster
Posts: 118
Joined: Sun Mar 05, 2006 7:25 am

Post by Lagoon »

Funny, it's three years I'm coding pol and I didn't know about the existance of labels... so this is an interesting feature: an updated escript guide :roll:
Shinigami
Former Developer
Posts: 308
Joined: Mon Jan 30, 2006 9:28 am

Post by Shinigami »

it's a bad feature... it's BASIC style... and will break any kind of structured coding

Shinigami
User avatar
Austin
Former Developer
Posts: 621
Joined: Wed Jan 25, 2006 2:30 am

Post by Austin »

Fortunately there is no 'goto' command, and the labels only work on loops.
Trying to remember which docs this was originally noted in...
Marilla

Post by Marilla »

hehe.. I have to agree with Shini; Spaghetti, anyone? Though as Austin notes, at least it can't be used for 'GOTO' type stuff. Ugh!

I am certainly not one to criticize others' coding methods, as I absolutely have my own bad habits. But I think that the desire for things like using labels to control code execution just means that there is likely a much better way to structure the code in question.

That said, though; the label feature here can be used just fine; You just have to keep in mind that though you have to put the labels 'before' the break, that the labels refer to the loops that you would be breaking out of, so just structure those properly.
Danielle
Grandmaster Poster
Posts: 104
Joined: Tue Feb 07, 2006 3:32 pm

Post by Danielle »

If it wasn't too much work, considering a working (but bad) method already exists, I'd also like to see the 'break #' idea implemented.

The label method is sloppy looking, and Shini said why else it's bad.
Marilla

Post by Marilla »

I think the proposed way is just as bad, actually. I think it's much better to encapsulate the loops in a function, and use return;, instead of trying to break; out of multiple loops at once, no matter the method.



A return makes it 100% clear where the code is going next, with no doubt at all. The break #; method could make things even more confusing than the existing method; They are really exactly the same thing, only this proposed idea has less flexibility, and does not come with labels to make some attempt to make it 'clear' where the code goes... but, well, they are both bad, IMO. But as far as I can tell, having something like this wouldn't harm anyone not using it (unlike, say, the Config Delete idea, which could slow down everything), so if this seems better to some then encapsulating things in a function, go for it. :wink:
Locked