# Stack Adapter: Haxe

## Language: Haxe

### Framework Detection

| Pattern | Framework | Route Style |
|---------|-----------|-------------|
| `import openfl` / `openfl.display` | OpenFL | Flash-like API, `addChild()`, `EventDispatcher` |
| `import flixel` / `flixel.FlxG` | HaxeFlixel | `FlxState`, `FlxSprite`, game framework |
| `import heaps` / `hxd.App` | Heaps | `hxd.App`, WebGL-focused game engine |
| `import react.ReactComponent` | React.hx | JSX transpilation, component lifecycle |
| `import tink.core` | Tink libraries | Macros, dependency injection |
| `import haxe.macro` | Haxe macros | Compile-time metaprogramming |

### Thresholds (Default)

| Metric | Limit | Notes |
|--------|-------|-------|
| Max function length | 35 lines | Haxe verbosity from type annotations and inline conditionals |
| Cyclomatic complexity | 8 | Moderate threshold — Haxe's pattern matching reduces nesting needs |
| Parameter count warning | >4 params | Excluding optional parameters with defaults; prefer object/struct init |
| Method count warning per class | >12 methods | Large classes often violate SRP in Haxe |

### DRY Ignore Patterns

1. **`@:structInit` class constructors**: Standard Haxe pattern where each data structure defines its own constructor with validation. While similar across DTOs, each has unique field validation logic. Not a violation unless identical structures should be unified.

2. **Enum switch exhaustive handling**: Repeated `switch` statements handling all enum variants is idiomatic Haxe, not duplication. Each context requires explicit variant handling for type safety.

3. **Platform conditional compilation blocks**: Repeated `#if js`, `#if cpp`, `#if python` blocks are necessary for multi-target Haxe code. Platform-specific implementations are expected, not DRY violations.

4. **Macro-generated boilerplate**: Code generated by `@:genericBuild`, `@:autoBuild`, or custom macros appears repetitive but is compile-time generated. Don't flag macro-expanded patterns as duplication.

5. **Property getter/setter pairs**: Haxe's `var prop(get, set)` syntax requires separate `get_prop()` and `set_prop()` methods. This is language-level property system, not duplication.

6. **Interface implementation stubs**: Multiple classes implementing the same interface with similar method signatures is standard polymorphism, not DRY violation.

### Framework Overrides

#### OpenFL
- Max function length: 40 lines (event handlers can include display list manipulation)
- Additional ignore patterns: `addEventListener()` repeated across display objects, `override public function render()` in custom sprites

#### HaxeFlixel
- Max function length: 45 lines (game state update loops can be longer)
- Additional ignore patterns: `override public function update(elapsed:Float)` in FlxState subclasses, sprite initialization blocks

#### Heaps
- Max function length: 40 lines
- Additional ignore patterns: `override function update(dt:Float)` in hxd.App subclasses, resource loading sequences

#### React.hx
- Max function length: 30 lines (component rendering should be concise)
- Additional ignore patterns: JSX return statements spanning multiple lines, `componentDidMount`/`componentWillUnmount` lifecycle pairs

#### Tink Libraries
- Max function length: 35 lines
- Additional ignore patterns: Dependency injection constructor patterns, macro-based serialization/deserialization methods

### Haxe-Specific Rules

#### Enum Exhaustiveness
- **Rule**: Always handle all enum variants explicitly in switch statements without default cases
- **Rationale**: Haxe compiler enforces exhaustiveness at compile time; adding default cases hides missing variant handling
- **Exception**: Only use default when documenting why future variants can be safely ignored

#### Platform Isolation
- **Rule**: Separate core business logic from platform-specific code using interfaces/adapters
- **Pattern**: Core logic in `src/core/`, platform adapters in `src/platform/js/`, `src/platform/cpp/`, etc.
- **Violation**: Mixing `#if js` conditionals with business logic in the same method

#### @:structInit Over Typedef
- **Rule**: Prefer `@:structInit` classes over typedef for complex data structures
- **Rationale**: Classes provide validation, methods, and better IDE support vs. plain typedefs
- **Exception**: Simple record types with no behavior can use typedef

#### Modern Function Type Syntax
- **Rule**: Use named parameter function types: `(name:String, age:Int)->Void` not `(String, Int)->Void`
- **Rationale**: Improves readability and prevents parameter order mistakes
- **Violation**: Positional-only function types in public APIs

#### Strict Static Typing
- **Rule**: Avoid `Dynamic` in public APIs; use proper type annotations
- **Exception**: Internal macro code or JSON parsing may require Dynamic temporarily
- **Violation**: Public methods returning or accepting untyped Dynamic values

#### Documentation Comment Style
- **Rule**: Use Haxe doc-comment format: `/**` opening, `*/` closing, no `*` prefix on interior lines
- **Example**:
  ```haxe
  /**
  Calculates the distance between two points.
  
  @param x1 First point X coordinate
  @param y1 First point Y coordinate
  @return Euclidean distance
  */
  ```
- **Violation**: Javadoc-style comments with `*` prefixes on each line