Port switch/case from AmpMod

[ampelectrecuted]

Add switch/case from ampmod. This requires a bit of structure changes in the compiler, you can reference this commit

[traycerai]

Plan

Observations

The OmniBlocks codebase is a sophisticated fork of TurboWarp/Scratch with a multi-repository architecture. The compiler lives in scratch-vm, visual block definitions in scratch-blocks, and the GUI in scratch-gui. The codebase already has infrastructure for multi-branch conditional blocks (as seen in the control category with control_if and control_if_else), and there's a mature block-switching addon that demonstrates handling control flow transformations. The GUI integrates with the VM compiler through event listeners and the block-switching addon provides a pattern for transforming between related block types.

The ticket references an AmpMod commit that implements switch/case with safety checks to prevent bad syntax generation. The comments indicate that AmpMod's implementation is similar to LibreKitten's but with additional safety checks. This suggests the implementation should focus on safe code generation and proper handling of case matching logic.

Approach

The switch/case block implementation will be executed across three repositories following the OmniBlocks architecture:

1. scratch-vm (compiler and runtime): Core block definitions, execution logic, and compiler code generation
2. scratch-blocks (visual definitions): Block shapes, mutations, and rendering
3. scratch-gui (frontend): Toolbox integration and block-switching addon support

The implementation will leverage the existing multi-branch conditional infrastructure and the block-switching addon pattern. The focus will be on safe code generation with proper case matching, fall-through prevention (or explicit handling), and integration with the compiler's IR system.

Implementation Steps

Phase 1: scratch-vm Repository Changes

1.1 Define Switch/Case Block Opcodes

File: src/blocks/scratch3_control.js (or equivalent control blocks file)

Add new block definitions for switch/case:

• Define control_switch block opcode with:

  • Input: SWITCH_VALUE (the expression to match)
  • Mutation support for dynamic case count
  • Block type: BlockType.CONDITIONAL with appropriate branchCount
  • Output: statement block (no return value)

• Define control_case block opcode with:

  • Input: CASE_VALUE (the value to match against)
  • Statement input: SUBSTACK (code to execute if matched)
  • Mutation support for case ordering
  • Output: statement block

• Define control_default_case block opcode with:

  • Statement input: SUBSTACK (default code to execute)
  • Output: statement block

Example structure:

Scratch3ControlBlocks.prototype.getInfo = function () {
    return {
        // ... existing blocks ...
        {
            opcode: 'control_switch',
            blockType: BlockType.CONDITIONAL,
            branchCount: 2, // default, will be mutable
            text: 'switch %1 %2',
            arguments: {
                SWITCH_VALUE: {
                    type: ArgumentType.STRING
                }
            }
        },
        {
            opcode: 'control_case',
            blockType: BlockType.CONDITIONAL,
            text: 'case %1 %2',
            arguments: {
                CASE_VALUE: {
                    type: ArgumentType.STRING
                }
            }
        }
    };
};

1.2 Implement Switch/Case Execution Logic

File: src/engine/execute.js or src/engine/sequencer.js

Implement the execution logic for switch/case blocks:

• Add handler for control_switch that:

  • Evaluates the switch expression
  • Iterates through case blocks
  • Performs strict equality comparison (or configurable comparison mode)
  • Executes the matching case's substack
  • Executes default case if no match found
  • Prevents fall-through (unless explicitly implemented)

• Add handler for control_case that:

  • Evaluates the case value
  • Compares with the switch value (comparison delegated to parent switch)
  • Executes substack if matched

Example pattern:

execute(block) {
    if (block.opcode === 'control_switch') {
        const switchValue = this.evaluateExpression(block.inputs.SWITCH_VALUE);
        const caseBlocks = this.getCaseBlocks(block);
        
        for (const caseBlock of caseBlocks) {
            const caseValue = this.evaluateExpression(caseBlock.inputs.CASE_VALUE);
            if (switchValue === caseValue) {
                this.executeSubstack(caseBlock.inputs.SUBSTACK);
                return;
            }
        }
        
        // Execute default case if present
        const defaultBlock = this.getDefaultCaseBlock(block);
        if (defaultBlock) {
            this.executeSubstack(defaultBlock.inputs.SUBSTACK);
        }
    }
}

1.3 Implement Compiler Code Generation

File: src/compiler/generate.js or equivalent compiler file

Implement efficient JavaScript code generation for switch/case:

• Generate JavaScript switch statement from Scratch switch/case blocks

• Implement safety checks to prevent bad syntax:

  • Validate case values are valid JavaScript literals
  • Escape string values properly
  • Handle numeric and string comparisons correctly
  • Generate proper break statements to prevent fall-through
  • Handle default case correctly

• Optimize for the compiler's IR (Intermediate Representation):

  • Generate efficient switch statements instead of nested if/else
  • Minimize generated code size
  • Ensure proper variable scoping

Example code generation:

generateSwitch(block) {
    const switchValue = this.generateExpression(block.inputs.SWITCH_VALUE);
    const caseBlocks = this.getCaseBlocks(block);
    
    let code = `switch (${switchValue}) {\n`;
    
    for (const caseBlock of caseBlocks) {
        const caseValue = this.generateCaseValue(caseBlock);
        const caseCode = this.generateSubstack(caseBlock.inputs.SUBSTACK);
        code += `  case ${caseValue}:\n${caseCode}\n    break;\n`;
    }
    
    const defaultBlock = this.getDefaultCaseBlock(block);
    if (defaultBlock) {
        const defaultCode = this.generateSubstack(defaultBlock.inputs.SUBSTACK);
        code += `  default:\n${defaultCode}\n    break;\n`;
    }
    
    code += `}\n`;
    return code;
}

1.4 Add Mutation Support

File: src/blocks/scratch3_control.js

Implement mutation handlers for dynamic case count:

• Add mutationToDom to serialize case count and case values
• Add domToMutation to deserialize case count and case values
• Support adding/removing cases dynamically
• Preserve case values during mutations

Phase 2: scratch-blocks Repository Changes

2.1 Define Visual Block Shapes

File: blocks_vertical/control.js (or equivalent)

Define the visual appearance of switch/case blocks:

• Create control_switch block definition with:

  • Input field for switch expression
  • Mutation support for dynamic case count
  • Proper nesting of case blocks
  • Control block color scheme

• Create control_case block definition with:

  • Input field for case value
  • Statement input for substack
  • Proper indentation and visual hierarchy
  • Control block color scheme

• Create control_default_case block definition with:

  • Statement input for substack
  • Visual distinction from regular cases
  • Control block color scheme

Example block definition:

Blockly.Blocks['control_switch'] = {
    init: function() {
        this.jsonInit({
            type: 'control_switch',
            message0: 'switch %1',
            args0: [
                {
                    type: 'input_value',
                    name: 'SWITCH_VALUE'
                }
            ],
            message1: '%1',
            args1: [
                {
                    type: 'input_statement',
                    name: 'CASES'
                }
            ],
            colour: Blockly.Colours.control.primary,
            colourSecondary: Blockly.Colours.control.secondary,
            colourTertiary: Blockly.Colours.control.tertiary
        });
    }
};

2.2 Implement Mutation Logic

File: blocks_vertical/control.js

Implement mutation handlers for dynamic case management:

• Add mutationToDom to serialize case count
• Add domToMutation to deserialize and rebuild case blocks
• Support adding/removing cases through UI
• Preserve case values during mutations
• Handle proper block connection management

2.3 Update Block Rendering

File: core/block_render_svg.js or equivalent

Ensure proper rendering of nested case blocks:

• Handle proper indentation for case blocks
• Render case blocks as children of switch block
• Ensure proper visual hierarchy
• Handle block connection points correctly

Phase 3: scratch-gui Repository Changes

3.1 Add Switch/Case to Control Toolbox

File: src/lib/make-toolbox-xml.js

Add switch/case block definitions to the control category (lines 397-455):

• Insert new block XML after the existing if/else blocks and before control_stop

• Define control_switch block with:

  • Value input for the switch expression
  • Shadow block of type text for the default value
  • Multiple case branches (initially 2 cases as default)
  • Proper nesting structure

• Define control_case block that represents individual case branches:

  • Value input for the case condition
  • Statement input for the case body

• Define control_default_case block for the default branch

Example XML to add:

<block type="control_switch">
    <value name="SWITCH_VALUE">
        <shadow type="text">
            <field name="TEXT"></field>
        </shadow>
    </value>
    <statement name="CASES">
        <block type="control_case">
            <value name="CASE_VALUE">
                <shadow type="text">
                    <field name="TEXT"></field>
                </shadow>
            </value>
        </block>
        <next>
            <block type="control_case">
                <value name="CASE_VALUE">
                    <shadow type="text">
                        <field name="TEXT"></field>
                    </shadow>
                </value>
            </block>
            <next>
                <block type="control_default_case">
                </block>
            </next>
        </next>
    </statement>
</block>

3.2 Update Block Switching Addon

File: src/addons/addons/block-switching/userscript.js

Add switch/case to the control block switches (around line 353-390):

• Add control_switch to the blockSwitches object
• Define switching relationships between control_if, control_if_else, and control_switch
• Handle the splitInputs for case branches when switching between block types
• Add switches between different numbers of cases (e.g., 2 cases ↔ 3 cases ↔ if/else)

Example pattern to add in the control section:

if (addon.settings.get("control")) {
    // ... existing switches ...
    blockSwitches["control_switch"] = [
        {
            opcode: "control_if",
            splitInputs: ["CASES"]
        },
        {
            opcode: "control_if_else",
            splitInputs: ["CASES"]
        },
        noopSwitch
    ];
    blockSwitches["control_if"] = [
        noopSwitch,
        {
            opcode: "control_if_else"
        },
        {
            opcode: "control_switch",
            createInputs: {
                CASES: {
                    // Create default case blocks
                }
            }
        }
    ];
    blockSwitches["control_if_else"] = [
        {
            opcode: "control_if",
            splitInputs: ["SUBSTACK2"]
        },
        noopSwitch,
        {
            opcode: "control_switch",
            createInputs: {
                CASES: {
                    // Create default case blocks
                }
            }
        }
    ];
}

3.3 Add Block Initialization in GUI

File: src/lib/blocks.js

Add initialization functions for the new switch/case blocks (similar to existing control blocks):

• Define menu functions if needed for case options
• Set up proper block colors using controlColors (line 155)
• Initialize any dynamic menus or dropdowns for case values
• Ensure proper integration with the VM's block definitions

3.4 Update Compiler Event Handling (if needed)

File: src/lib/vm-listener-hoc.jsx

Verify that existing compiler event handlers (lines 70-76) properly handle switch/case blocks:

• The COMPILER_OPTIONS_CHANGED handler should work without modification
• The COMPILE_ERROR handler (lines 135-147) should catch any switch/case compilation errors
• No additional event listeners should be needed unless the VM adds switch-specific events

3.5 Test with Compiler Addon

File: src/addons/addons/tw-disable-compiler/userscript.js

Ensure switch/case blocks work correctly with compiler disabled:

• Test that switch/case executes properly in interpreted mode
• Verify that the debugger addon can step through switch/case blocks
• Check that the editor-stepping addon highlights switch/case blocks correctly

3.6 Update Documentation and Examples

File: src/examples/extensions/example-extension.js

Update the example extension to demonstrate switch/case usage:

• Modify the example conditional block to show switch/case pattern
• Update comments about dynamic branch count support
• Add documentation about the branchCount property for switch blocks

3.7 Add Translation Support

Files: Translation files in src/lib/libraries/decks/*-steps.js

Add translation keys for switch/case blocks:

• Add CONTROL_SWITCH message key
• Add CONTROL_CASE message key
• Add CONTROL_DEFAULT_CASE message key
• Ensure all language files include these translations

Phase 4: Integration and Testing

4.1 Integration Testing

Create test scenarios to verify:

• Switch/case blocks appear in the control category toolbox
• Blocks can be dragged and connected properly
• Block switching addon correctly transforms between if/else and switch/case
• Compiler generates efficient code for switch statements
• Interpreted mode executes switch/case correctly
• Projects with switch/case blocks save and load properly
• Backward compatibility: projects without switch/case still work
• Safety checks prevent bad syntax generation
• Case matching works correctly (strict equality)
• Default case executes when no match found

4.2 Safety Validation

Implement safety checks to ensure:

• Case values are properly escaped and validated
• Generated JavaScript is syntactically correct
• No injection vulnerabilities in case value handling
• Proper handling of edge cases (empty cases, duplicate values, etc.)
• Compiler error messages are clear and helpful

4.3 Performance Testing

Verify that:

• Compiled switch statements are more efficient than nested if/else
• Code generation is fast and doesn't impact editor responsiveness
• Runtime execution is performant for large switch statements

Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│                    scratch-gui (Frontend)                   │
├─────────────────────────────────────────────────────────────┤
│ • make-toolbox-xml.js: Add switch/case to control category  │
│ • block-switching addon: Transform if/else ↔ switch/case    │
│ • blocks.js: Initialize block definitions                   │
│ • Translation support for switch/case blocks                │
└────────────────┬────────────────────────────────┬───────────┘
                 │                                │
                 ▼                                ▼
        ┌─────────────────────┐        ┌──────────────────────┐
        │  scratch-blocks     │        │   scratch-vm         │
        │  (Visual Defs)      │        │  (Compiler/Runtime)  │
        ├─────────────────────┤        ├──────────────────────┤
        │ • Block shapes      │        │ • Block opcodes      │
        │ • Mutations         │        │ • Execution logic    │
        │ • Rendering         │        │ • Code generation    │
        │ • Case nesting      │        │ • Safety checks      │
        └─────────────────────┘        └──────────────────────┘

Key Files Reference

scratch-gui:

• src/lib/make-toolbox-xml.js - Add switch/case to control category (lines 397-455)
• src/addons/addons/block-switching/userscript.js - Add block switching support (lines 353-390)
• src/lib/blocks.js - Initialize block definitions with VM
• src/lib/vm-listener-hoc.jsx - Compiler event integration (already handles errors)
• package.json - Dependencies: scratch-vm (line 100), scratch-blocks (line 96)

scratch-vm (OmniBlocks/scratch-vm#develop):

• src/blocks/scratch3_control.js - Block definitions and execution logic
• src/engine/execute.js or src/engine/sequencer.js - Execution handlers
• src/compiler/generate.js - Code generation with safety checks

scratch-blocks (OmniBlocks/scratch-blocks#develop-builds):

• blocks_vertical/control.js - Visual block definitions
• core/block_render_svg.js - Rendering logic for nested blocks

Dependencies on Other Repositories

Critical: The majority of switch/case implementation must be done in:

1. scratch-vm (github:OmniBlocks/scratch-vm#develop) - Compiler changes, block execution logic, IR generation, safety checks
2. scratch-blocks (github:OmniBlocks/scratch-blocks#develop-builds) - Visual block definitions, mutation logic, rendering

The scratch-gui changes are primarily for:

• Adding blocks to the toolbox
• Integrating with the block switching addon
• Ensuring proper UI/UX for the new blocks
• Translation support

Implementation Notes

• The implementation should prioritize safety checks to prevent bad syntax generation, as mentioned in the ticket comments
• Case matching should use strict equality (===) by default, with potential for configurable comparison modes
• The compiler should generate efficient JavaScript switch statements instead of nested if/else
• The block-switching addon should allow seamless transformation between if/else and switch/case blocks
• All changes should maintain backward compatibility with existing projects

Import In IDE

🤖 Prompt for AI Agents

## Observations

The OmniBlocks codebase is a sophisticated fork of TurboWarp/Scratch with a multi-repository architecture. The compiler lives in `scratch-vm`, visual block definitions in `scratch-blocks`, and the GUI in `scratch-gui`. The codebase already has infrastructure for multi-branch conditional blocks (as seen in the control category with `control_if` and `control_if_else`), and there's a mature `block-switching` addon that demonstrates handling control flow transformations. The GUI integrates with the VM compiler through event listeners and the block-switching addon provides a pattern for transforming between related block types.

The ticket references an AmpMod commit that implements switch/case with safety checks to prevent bad syntax generation. The comments indicate that AmpMod's implementation is similar to LibreKitten's but with additional safety checks. This suggests the implementation should focus on safe code generation and proper handling of case matching logic.

## Approach

The switch/case block implementation will be executed across three repositories following the OmniBlocks architecture:

1. **scratch-vm** (compiler and runtime): Core block definitions, execution logic, and compiler code generation
2. **scratch-blocks** (visual definitions): Block shapes, mutations, and rendering
3. **scratch-gui** (frontend): Toolbox integration and block-switching addon support

The implementation will leverage the existing multi-branch conditional infrastructure and the block-switching addon pattern. The focus will be on safe code generation with proper case matching, fall-through prevention (or explicit handling), and integration with the compiler's IR system.

## Implementation Steps

### Phase 1: scratch-vm Repository Changes

#### 1.1 Define Switch/Case Block Opcodes

**File**: `src/blocks/scratch3_control.js` (or equivalent control blocks file)

Add new block definitions for switch/case:

- Define `control_switch` block opcode with:
  - Input: `SWITCH_VALUE` (the expression to match)
  - Mutation support for dynamic case count
  - Block type: `BlockType.CONDITIONAL` with appropriate `branchCount`
  - Output: statement block (no return value)

- Define `control_case` block opcode with:
  - Input: `CASE_VALUE` (the value to match against)
  - Statement input: `SUBSTACK` (code to execute if matched)
  - Mutation support for case ordering
  - Output: statement block

- Define `control_default_case` block opcode with:
  - Statement input: `SUBSTACK` (default code to execute)
  - Output: statement block

Example structure:
```javascript
Scratch3ControlBlocks.prototype.getInfo = function () {
    return {
        // ... existing blocks ...
        {
            opcode: 'control_switch',
            blockType: BlockType.CONDITIONAL,
            branchCount: 2, // default, will be mutable
            text: 'switch %1 %2',
            arguments: {
                SWITCH_VALUE: {
                    type: ArgumentType.STRING
                }
            }
        },
        {
            opcode: 'control_case',
            blockType: BlockType.CONDITIONAL,
            text: 'case %1 %2',
            arguments: {
                CASE_VALUE: {
                    type: ArgumentType.STRING
                }
            }
        }
    };
};
```

#### 1.2 Implement Switch/Case Execution Logic

**File**: `src/engine/execute.js` or `src/engine/sequencer.js`

Implement the execution logic for switch/case blocks:

- Add handler for `control_switch` that:
  - Evaluates the switch expression
  - Iterates through case blocks
  - Performs strict equality comparison (or configurable comparison mode)
  - Executes the matching case's substack
  - Executes default case if no match found
  - Prevents fall-through (unless explicitly implemented)

- Add handler for `control_case` that:
  - Evaluates the case value
  - Compares with the switch value (comparison delegated to parent switch)
  - Executes substack if matched

Example pattern:
```javascript
execute(block) {
    if (block.opcode === 'control_switch') {
        const switchValue = this.evaluateExpression(block.inputs.SWITCH_VALUE);
        const caseBlocks = this.getCaseBlocks(block);
        
        for (const caseBlock of caseBlocks) {
            const caseValue = this.evaluateExpression(caseBlock.inputs.CASE_VALUE);
            if (switchValue === caseValue) {
                this.executeSubstack(caseBlock.inputs.SUBSTACK);
                return;
            }
        }
        
        // Execute default case if present
        const defaultBlock = this.getDefaultCaseBlock(block);
        if (defaultBlock) {
            this.executeSubstack(defaultBlock.inputs.SUBSTACK);
        }
    }
}
```

#### 1.3 Implement Compiler Code Generation

**File**: `src/compiler/generate.js` or equivalent compiler file

Implement efficient JavaScript code generation for switch/case:

- Generate JavaScript `switch` statement from Scratch switch/case blocks
- Implement safety checks to prevent bad syntax:
  - Validate case values are valid JavaScript literals
  - Escape string values properly
  - Handle numeric and string comparisons correctly
  - Generate proper `break` statements to prevent fall-through
  - Handle default case correctly

- Optimize for the compiler's IR (Intermediate Representation):
  - Generate efficient switch statements instead of nested if/else
  - Minimize generated code size
  - Ensure proper variable scoping

Example code generation:
```javascript
generateSwitch(block) {
    const switchValue = this.generateExpression(block.inputs.SWITCH_VALUE);
    const caseBlocks = this.getCaseBlocks(block);
    
    let code = `switch (${switchValue}) {\n`;
    
    for (const caseBlock of caseBlocks) {
        const caseValue = this.generateCaseValue(caseBlock);
        const caseCode = this.generateSubstack(caseBlock.inputs.SUBSTACK);
        code += `  case ${caseValue}:\n${caseCode}\n    break;\n`;
    }
    
    const defaultBlock = this.getDefaultCaseBlock(block);
    if (defaultBlock) {
        const defaultCode = this.generateSubstack(defaultBlock.inputs.SUBSTACK);
        code += `  default:\n${defaultCode}\n    break;\n`;
    }
    
    code += `}\n`;
    return code;
}
```

#### 1.4 Add Mutation Support

**File**: `src/blocks/scratch3_control.js`

Implement mutation handlers for dynamic case count:

- Add `mutationToDom` to serialize case count and case values
- Add `domToMutation` to deserialize case count and case values
- Support adding/removing cases dynamically
- Preserve case values during mutations

### Phase 2: scratch-blocks Repository Changes

#### 2.1 Define Visual Block Shapes

**File**: `blocks_vertical/control.js` (or equivalent)

Define the visual appearance of switch/case blocks:

- Create `control_switch` block definition with:
  - Input field for switch expression
  - Mutation support for dynamic case count
  - Proper nesting of case blocks
  - Control block color scheme

- Create `control_case` block definition with:
  - Input field for case value
  - Statement input for substack
  - Proper indentation and visual hierarchy
  - Control block color scheme

- Create `control_default_case` block definition with:
  - Statement input for substack
  - Visual distinction from regular cases
  - Control block color scheme

Example block definition:
```javascript
Blockly.Blocks['control_switch'] = {
    init: function() {
        this.jsonInit({
            type: 'control_switch',
            message0: 'switch %1',
            args0: [
                {
                    type: 'input_value',
                    name: 'SWITCH_VALUE'
                }
            ],
            message1: '%1',
            args1: [
                {
                    type: 'input_statement',
                    name: 'CASES'
                }
            ],
            colour: Blockly.Colours.control.primary,
            colourSecondary: Blockly.Colours.control.secondary,
            colourTertiary: Blockly.Colours.control.tertiary
        });
    }
};
```

#### 2.2 Implement Mutation Logic

**File**: `blocks_vertical/control.js`

Implement mutation handlers for dynamic case management:

- Add `mutationToDom` to serialize case count
- Add `domToMutation` to deserialize and rebuild case blocks
- Support adding/removing cases through UI
- Preserve case values during mutations
- Handle proper block connection management

#### 2.3 Update Block Rendering

**File**: `core/block_render_svg.js` or equivalent

Ensure proper rendering of nested case blocks:

- Handle proper indentation for case blocks
- Render case blocks as children of switch block
- Ensure proper visual hierarchy
- Handle block connection points correctly

### Phase 3: scratch-gui Repository Changes

#### 3.1 Add Switch/Case to Control Toolbox

**File**: `src/lib/make-toolbox-xml.js`

Add switch/case block definitions to the control category (lines 397-455):

- Insert new block XML after the existing if/else blocks and before `control_stop`
- Define `control_switch` block with:
  - Value input for the switch expression
  - Shadow block of type `text` for the default value
  - Multiple case branches (initially 2 cases as default)
  - Proper nesting structure

- Define `control_case` block that represents individual case branches:
  - Value input for the case condition
  - Statement input for the case body

- Define `control_default_case` block for the default branch

Example XML to add:
```xml
<block type="control_switch">
    <value name="SWITCH_VALUE">
        <shadow type="text">
            <field name="TEXT"></field>
        </shadow>
    </value>
    <statement name="CASES">
        <block type="control_case">
            <value name="CASE_VALUE">
                <shadow type="text">
                    <field name="TEXT"></field>
                </shadow>
            </value>
        </block>
        <next>
            <block type="control_case">
                <value name="CASE_VALUE">
                    <shadow type="text">
                        <field name="TEXT"></field>
                    </shadow>
                </value>
            </block>
            <next>
                <block type="control_default_case">
                </block>
            </next>
        </next>
    </statement>
</block>
```

#### 3.2 Update Block Switching Addon

**File**: `src/addons/addons/block-switching/userscript.js`

Add switch/case to the control block switches (around line 353-390):

- Add `control_switch` to the `blockSwitches` object
- Define switching relationships between `control_if`, `control_if_else`, and `control_switch`
- Handle the `splitInputs` for case branches when switching between block types
- Add switches between different numbers of cases (e.g., 2 cases ↔ 3 cases ↔ if/else)

Example pattern to add in the control section:
```javascript
if (addon.settings.get("control")) {
    // ... existing switches ...
    blockSwitches["control_switch"] = [
        {
            opcode: "control_if",
            splitInputs: ["CASES"]
        },
        {
            opcode: "control_if_else",
            splitInputs: ["CASES"]
        },
        noopSwitch
    ];
    blockSwitches["control_if"] = [
        noopSwitch,
        {
            opcode: "control_if_else"
        },
        {
            opcode: "control_switch",
            createInputs: {
                CASES: {
                    // Create default case blocks
                }
            }
        }
    ];
    blockSwitches["control_if_else"] = [
        {
            opcode: "control_if",
            splitInputs: ["SUBSTACK2"]
        },
        noopSwitch,
        {
            opcode: "control_switch",
            createInputs: {
                CASES: {
                    // Create default case blocks
                }
            }
        }
    ];
}
```

#### 3.3 Add Block Initialization in GUI

**File**: `src/lib/blocks.js`

Add initialization functions for the new switch/case blocks (similar to existing control blocks):

- Define menu functions if needed for case options
- Set up proper block colors using `controlColors` (line 155)
- Initialize any dynamic menus or dropdowns for case values
- Ensure proper integration with the VM's block definitions

#### 3.4 Update Compiler Event Handling (if needed)

**File**: `src/lib/vm-listener-hoc.jsx`

Verify that existing compiler event handlers (lines 70-76) properly handle switch/case blocks:

- The `COMPILER_OPTIONS_CHANGED` handler should work without modification
- The `COMPILE_ERROR` handler (lines 135-147) should catch any switch/case compilation errors
- No additional event listeners should be needed unless the VM adds switch-specific events

#### 3.5 Test with Compiler Addon

**File**: `src/addons/addons/tw-disable-compiler/userscript.js`

Ensure switch/case blocks work correctly with compiler disabled:

- Test that switch/case executes properly in interpreted mode
- Verify that the debugger addon can step through switch/case blocks
- Check that the `editor-stepping` addon highlights switch/case blocks correctly

#### 3.6 Update Documentation and Examples

**File**: `src/examples/extensions/example-extension.js`

Update the example extension to demonstrate switch/case usage:

- Modify the example conditional block to show switch/case pattern
- Update comments about dynamic branch count support
- Add documentation about the `branchCount` property for switch blocks

#### 3.7 Add Translation Support

**Files**: Translation files in `src/lib/libraries/decks/*-steps.js`

Add translation keys for switch/case blocks:

- Add `CONTROL_SWITCH` message key
- Add `CONTROL_CASE` message key
- Add `CONTROL_DEFAULT_CASE` message key
- Ensure all language files include these translations

### Phase 4: Integration and Testing

#### 4.1 Integration Testing

Create test scenarios to verify:

- Switch/case blocks appear in the control category toolbox
- Blocks can be dragged and connected properly
- Block switching addon correctly transforms between if/else and switch/case
- Compiler generates efficient code for switch statements
- Interpreted mode executes switch/case correctly
- Projects with switch/case blocks save and load properly
- Backward compatibility: projects without switch/case still work
- Safety checks prevent bad syntax generation
- Case matching works correctly (strict equality)
- Default case executes when no match found

#### 4.2 Safety Validation

Implement safety checks to ensure:

- Case values are properly escaped and validated
- Generated JavaScript is syntactically correct
- No injection vulnerabilities in case value handling
- Proper handling of edge cases (empty cases, duplicate values, etc.)
- Compiler error messages are clear and helpful

#### 4.3 Performance Testing

Verify that:

- Compiled switch statements are more efficient than nested if/else
- Code generation is fast and doesn't impact editor responsiveness
- Runtime execution is performant for large switch statements

## Architecture Diagram

```
┌─────────────────────────────────────────────────────────────┐
│                    scratch-gui (Frontend)                   │
├─────────────────────────────────────────────────────────────┤
│ • make-toolbox-xml.js: Add switch/case to control category  │
│ • block-switching addon: Transform if/else ↔ switch/case    │
│ • blocks.js: Initialize block definitions                   │
│ • Translation support for switch/case blocks                │
└────────────────┬────────────────────────────────┬───────────┘
                 │                                │
                 ▼                                ▼
        ┌─────────────────────┐        ┌──────────────────────┐
        │  scratch-blocks     │        │   scratch-vm         │
        │  (Visual Defs)      │        │  (Compiler/Runtime)  │
        ├─────────────────────┤        ├──────────────────────┤
        │ • Block shapes      │        │ • Block opcodes      │
        │ • Mutations         │        │ • Execution logic    │
        │ • Rendering         │        │ • Code generation    │
        │ • Case nesting      │        │ • Safety checks      │
        └─────────────────────┘        └──────────────────────┘
```

## Key Files Reference

**scratch-gui**:
- `src/lib/make-toolbox-xml.js` - Add switch/case to control category (lines 397-455)
- `src/addons/addons/block-switching/userscript.js` - Add block switching support (lines 353-390)
- `src/lib/blocks.js` - Initialize block definitions with VM
- `src/lib/vm-listener-hoc.jsx` - Compiler event integration (already handles errors)
- `package.json` - Dependencies: scratch-vm (line 100), scratch-blocks (line 96)

**scratch-vm** (OmniBlocks/scratch-vm#develop):
- `src/blocks/scratch3_control.js` - Block definitions and execution logic
- `src/engine/execute.js` or `src/engine/sequencer.js` - Execution handlers
- `src/compiler/generate.js` - Code generation with safety checks

**scratch-blocks** (OmniBlocks/scratch-blocks#develop-builds):
- `blocks_vertical/control.js` - Visual block definitions
- `core/block_render_svg.js` - Rendering logic for nested blocks

## Dependencies on Other Repositories

**Critical**: The majority of switch/case implementation must be done in:

1. **scratch-vm** (github:OmniBlocks/scratch-vm#develop) - Compiler changes, block execution logic, IR generation, safety checks
2. **scratch-blocks** (github:OmniBlocks/scratch-blocks#develop-builds) - Visual block definitions, mutation logic, rendering

The scratch-gui changes are primarily for:
- Adding blocks to the toolbox
- Integrating with the block switching addon
- Ensuring proper UI/UX for the new blocks
- Translation support

## Implementation Notes

- The implementation should prioritize safety checks to prevent bad syntax generation, as mentioned in the ticket comments
- Case matching should use strict equality (===) by default, with potential for configurable comparison modes
- The compiler should generate efficient JavaScript switch statements instead of nested if/else
- The block-switching addon should allow seamless transformation between if/else and switch/case blocks
- All changes should maintain backward compatibility with existing projects

---

Execution Information

Branch: main
Commit: 5fc13f4

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[github-actions]

Hi @ampelectrecuted!

It looks like you're suggesting porting over the feature from AmpMod to OmniBlocks. You've also shared a helpful reference to the relevant commit in AmpMod's repository—thanks for that! From what you've mentioned, implementing this will likely involve making some structural updates to the compiler. This sounds like a valuable addition and could open up some versatile control flow options for users.

Let me know if there are additional details or specific challenges you think the team should focus on during this implementation!

[github-actions]

🎭 Issue Poem

In the realm of OmniBlocks, where ideas take flight,
A switch/case beckons, oh what a delight!
With tweaks to the compiler, let's pave the way,
For AmpMod's magic to join in the play.

So gather your courage, with code let’s engage,
Structure's the key to this wondrous new page.
With laughter and reason, let’s craft and explore,
Unlocking new pathways, who knows what's in store? 🎉

---

Generated with ❤️ by the OmniBlocks Poetry Bot

[ampelectrecuted]

@coderabbitai do you agree

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the full details of issue `#786`
gh issue view 786 --repo OmniBlocks/scratch-gui --json title,body,author,labels,url

Length of output: 1120

---

@ampelectrecuted Yes, I agree this is a valuable addition to OmniBlocks. Here's my assessment:

Why it makes sense:

• Standard control flow: Switch/case is a fundamental programming construct that provides cleaner, more readable code compared to long if-else chains
• Proven implementation: The feature already exists in AmpMod with a reference commit, which significantly reduces implementation risk
• User value: Gives users more versatile control flow options for complex conditional logic

Key considerations:

• Compiler complexity: The structural changes to the compiler will need careful planning, but the reference commit provides a clear implementation path
• Testing coverage: The "needs-careful-testing" label is appropriate—you'll want to ensure edge cases are covered (fall-through behavior, default cases, type coercion in case matching, etc.)
• Performance: Switch statements can be more performant than if-else chains for multiple conditions
• Consistency: Bringing feature parity between AmpMod and OmniBlocks strengthens the ecosystem

The high-priority label seems justified given the utility of this feature. The fact that you've already implemented it successfully in AmpMod is a strong indicator that the architecture can support it well.

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-05T01:48:23.435Z
Learning: OmniBlocks/scratch-gui workflow preference: Open tracking issues for CI/automation behavior changes; assign to supervoidcoder; include backlinks to the PR and the exact comment requesting the change.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: In OmniBlocks/scratch-gui, ampelectrecuted does not want CodeRabbit to use  mode or agent features unless explicitly requested. Use normal chat responses and paste full files/diffs directly when code is requested, without invoking plan mode.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-12T12:05:08.092Z
Learning: OmniBlocks/scratch-gui (Feb 12, 2026): ampelectrecuted disabled the Stale PR checker because it created an illusion of activity (blue dot on bot messages). Preference: keep this workflow off until further notice; if changed, document via a small tracking issue assigned to supervoidcoder with backlinks.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-02T21:10:54.683Z
Learning: OmniBlocks/scratch-gui: Issue `#460` was successfully resolved by ampelectrecuted on December 2, 2025. After accidentally pushing upstream/develop to main (wiping all custom code), ampelectrecuted immediately identified the issue, found a backup branch that survived due to a failed cleanup script, created a clean revert, and deployed a looping force-push recovery script that successfully restored 100% of the OmniBlocks codebase once supervoidcoder enabled force pushing in the "cool" ruleset. The incident parallels the famous 1998 Pixar Toy Story 2 deletion disaster. As recognition, an easter egg will be added to the menu bar (tracking issue created).

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-02T21:12:22.417Z
Learning: OmniBlocks/scratch-gui: Issue `#460` was successfully resolved by ampelectrecuted on December 2, 2025. After accidentally pushing upstream/develop to main (wiping all custom code), ampelectrecuted immediately identified the issue, found a backup branch that survived due to a failed cleanup script, created a clean revert, and deployed a looping force-push recovery script that successfully restored 100% of the OmniBlocks codebase once supervoidcoder enabled force pushing in the "cool" ruleset. The incident parallels the famous 1998 Pixar Toy Story 2 deletion disaster. As recognition, an easter egg will be added to the menu bar (tracking issue `#461` created).

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui moderation preference: When CodeRabbit detects a human comment with strong profanity or a clear Code of Conduct violation (e.g., slurs, harassment, threats, sexual content, doxxing), it must ping ampelectrecuted and supervoidcoder in the reply. Do not ping for mild words like “crap” or “heck.” Do not trigger on bot/CI comments. Keep the tone calm and optionally include a brief CoC reminder. Applies only within OmniBlocks/scratch-gui.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-05T16:58:18.936Z
Learning: OmniBlocks/scratch-gui uses ulti.yaml workflow with GitHub Models AI (Mistral-3B via actions/ai-inferencev1) for issue analysis, categorization, duplicate detection, and automated moderation with keyword-based actions like [SPAM], [SECURITY], [CLOSE], [LOCK], [LOCKDOWN].

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T19:06:53.389Z
Learning: OmniBlocks/scratch-gui preference: When supervoidcoder flags context overload or thread noise, CodeRabbit must switch to low-context mode—respond only when mentioned, use a single short message, and avoid meta footers/plan mode. Ask before minimizing prior bot comments.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-04T16:32:04.480Z
Learning: In OmniBlocks/scratch-gui, supervoidcoder wants to maintain OmniBlocks-specific UltraBox modifications by forking ultrabox_typescript into a separate OmniBlocks/ultrabox repository with clean TypeScript source code, then using GitHub Actions to automatically build and deploy the minified beepbox_editor.min.js to scratch-gui's static/ folder on every push.

---

Learnt from: 8to16
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-22T18:44:53.269Z
Learning: As of January 22, 2026, 8to16 is considering a full rewrite of ampmod and potentially OmniBlocks to eliminate any linkage with both Scratch and TurboWarp. They may pursue either a hard decouple (no branding/network ties) or a clean-room rewrite to remove legal derivation.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-27T22:15:17.812Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit should only respond to comments that directly address coderabbitai. If a comment is directed at another bot (e.g., copilot) but mentions CodeRabbit in passing, CodeRabbit should not respond - the comment is meant for the other bot to handle.

---

💡 Use @coderabbitai plan to create a plan for code changes

[ampelectrecuted]

also @someCatInTheWorld @coderabbitai ampmod's switch/case is similar to librekitten's one but with safety checks so it doesn't generate bad syntax