0

Is there an equal to named blocks in Haxe (as there was in Action Script 3)? I don't know if 'named block' is the correct term.

Given the following example (a basic example to highlight a point):

    singleCollision: {
            for (teleport in teleports) {
                if ( overlap(player, teleport ) ) {
                    onTeleport(player, teleport);
                    break singleCollision;
                }
            }

            for (chest in chests) {
                if ( overlap(player, chest ) ) {
                    onChest(player, chest);
                    break singleCollision;
                }
            }

            for (shop in shops) {
                if ( overlap(player, shop ) ) {
                    onShop(player, shop);
                    break singleCollision;
                }
            }
    }

If a collision occurs, break the block and continue. I know there are alternatives such as inline functions, etc, but more curious to know if Haxe supports something similar.

A good example is found here: http://jacksondunstan.com/articles/1228

Chris
  • 43,908
  • 26
  • 122
  • 165

2 Answers2

0

It's usually called code labels or GOTO labels.

No, there is no such thing in haxe. (And in some of it's backends.)

Spaghetty code is considered a bad practise for a long time already. Use conditioned loops, they are much clearer.

stroncium
  • 1,430
  • 9
  • 8
  • While I agree, there is a place, especially when flattening arrow code http://blog.codinghorror.com/flattening-arrow-code/. In this case I don't know how well conditional loops would work, it would only further drive the arrow to the right – Chris Jul 14 '14 at 14:04
  • @Chris But there is nothing in this article about code labels. And I doubt using them could fix the problem without going to pure GOTO hell. Actually, most of such cases can be fixed just by clever thinking in my experience. And if yhou have a couple of places when you really need deep nesting - why not, you really need it, right?And the operations behind the code will be complex enough to justify making code slightly more complex. Offtopic tho... – stroncium Jul 15 '14 at 10:38
-1

If you use try-catch, you can detect a codebreak position:

try {
        for (teleport in teleports) {
            if ( overlap(player, teleport ) ) {
                onTeleport(player, teleport);
                throw 0;
            }
        }

        for (chest in chests) {
            if ( overlap(player, chest ) ) {
                onChest(player, chest);
                throw 1;
            }
        }

        for (shop in shops) {
            if ( overlap(player, shop ) ) {
                onShop(player, shop);
                throw 2;
            }
        }
}
catch(e:Dynamic)
{
        switch (e) {
             ...
        }
}
Vox
  • 59
  • 2
  • Using exceptions for flow control should be considered bad practice: http://stackoverflow.com/questions/729379/why-not-use-exceptions-as-regular-flow-of-control – Richard Walton Jul 14 '14 at 23:34
  • I'm not convinced. I tested my code having several long lasting loops in a try-catch block on the Neko platform, and performance didn't change. I would say: it is a bad idea to put try-catch block inside the loop, while loop inside the try-catch doesn't make a big difference. Throw is about (correct me if I'm wrong): 1. positioning stack to the catch block 2. recovering previous registers 3. passing thrown object (which can be optimised as static object instead of new creation). If you ask me, there is no real reason for poor performance on some virtual machines. – Vox Jul 15 '14 at 00:49
  • But that's not the point: it is possible to do the same by using a function making return instead of the throw. However, inlining such function can be a bad idea if compiler decides to make a local function which will make a copy of all external variables used in such function on the heap. – Vox Jul 15 '14 at 00:57
  • It's about using the right tools for the job - Exceptions aren't the tool for flow control. – Richard Walton Jul 15 '14 at 10:46