Blog › ICP guides

ELENA developer on retainer: message-based dispatch, Protocol interface, mixin composition, dynamic dispatch, and ELENA object-oriented programming on monthly retainer

November 16, 2026 · ~16 min read

An ELENA program with two classes implementing a Protocol was producing five wrong dispatch calls per run. The program had a client object that called a Protocol method on a dispatch target. The dispatch target was assigned a singleton instance from a class that implemented the Protocol through a mixin. The mixin’s method implementation had a supermethod call — a call intended to invoke the next method up the composition chain. The supermethod call incorrectly forwarded to the base singleton’s default implementation rather than routing through the mixin’s own Protocol method chain. ELENA’s dispatch model for mixin-composed classes routes method calls through a specific resolution order: the mixin’s methods are composed into the class, and supermethod calls within a mixin method resolve to the class’s own next implementation in the chain, not to the base singleton’s implementation of the same name. The mixin had been designed with an explicit supermethod call that assumed it would always forward to the Protocol’s declared method signature on the base singleton. Instead, in the composition context, the supermethod resolved to the base singleton’s general-purpose default handler, which returned a wrong result for the Protocol-typed invocation. Five wrong dispatch calls per run. The ELENA developer on retainer diagnosed the mixin supermethod forwarding mismatch: the mixin method was restructured to use the correct message forwarding pattern — an explicit message forward to the Protocol method rather than a supermethod bypass — removing the dependency on supermethod resolution order and making the dispatch chain explicit. Wrong dispatch calls per run: 5 → 0.

The work log entry read “fixed mixin dispatch bug, 16h.” It names the symptom and duration. It cannot explain to a client why ELENA’s supermethod dispatch in a mixin context resolves differently from what a developer familiar with Smalltalk or Java inheritance might expect — in classical single-inheritance OOP, super.method() unambiguously calls the superclass’s version of the same method; in ELENA’s mixin composition model, the “super” in a mixin method resolves within the composition chain of the class into which the mixin is composed, which may not be the same class as the one the mixin developer was thinking about when writing the supermethod call. It cannot explain why the fix required tracing the entire dispatch chain from the Protocol declaration through the class’s mixin composition list to identify which method each supermethod call actually resolved to (the tracing requires understanding which methods are contributed by each mixin in the composition order, which method the class itself declares, and which method the base object or singleton declares, then following the supermethod resolution from the point of the failing call through each step of this chain), or why an explicit message forward was safer than restructuring the supermethod chain (an explicit message forward sends a named message to a named target, making the dispatch destination visible in the code; a supermethod call hides the resolution in the composition chain and will silently change behavior if the composition order changes or if a new mixin is inserted between the calling mixin and its current supermethod target). The 16 hours of dispatch chain tracing, Protocol binding analysis, and message forwarding pattern redesign are invisible in the diff beyond the removed supermethod call and the added explicit message forward.

ELENA message-based dispatch: Protocol interfaces, class implementation, and dynamic dispatch resolution

ELENA is a pure message-passing object-oriented language designed by Alexei Rakov. Every operation in ELENA is a message send. There are no operators, no function calls, no procedure calls — only messages sent to objects. An integer addition a + b is sugar for sending the message + with argument b to the object a. The receiving object’s response is determined by its class hierarchy: the runtime looks for a method handler for the message in the class of the receiver, then in the class’s mixin composition, then in the parent class chain, until a handler is found or the message is forwarded to a generic handler. If no handler is found anywhere in the chain and no generic handler is declared, the runtime raises an error. This pure message model means that ELENA code is highly polymorphic by default: any object that responds to a given message can serve as the target for any code that sends that message, without requiring an explicit type declaration.

Protocol declarations are ELENA’s mechanism for naming a set of messages that an object must respond to. A Protocol is similar to an interface in Java or a protocol in Swift: it declares method signatures without providing implementations. A class implements a Protocol by declaring the Protocol in its interface and providing method bodies for each signature. Protocol-typed variables and parameters restrict the set of objects that can be assigned to them: only objects whose classes implement the Protocol are valid. This restriction enables static verification and IDE tooling: the compiler can verify that a message send through a Protocol-typed variable will find a handler, because the Protocol declares that handler must exist. Protocol dispatch is how ELENA enables abstraction without sacrificing the pure message model: the Protocol names the message contract, the class provides the implementation, and the client sends messages to Protocol-typed variables without knowing the concrete class at compile time.

Dynamic dispatch in ELENA resolves method calls at runtime based on the actual class of the receiver, not the static type of the variable through which the message was sent. A Protocol-typed variable holding an instance of class A will dispatch to class A’s method implementations, not to the Protocol’s declaration. This is standard late binding: the dispatch target is the object’s runtime class, and the method resolution follows that class’s composition chain. The dispatch chain for a mixin-composed class follows a specific order: (1) methods declared directly in the class; (2) methods contributed by mixins, in the order the mixins are listed in the class composition; (3) methods inherited from the parent class; (4) generic handler, if declared. Within this chain, a method in step (2) that calls a supermethod is following step (3) next — the parent class’s method — unless the class itself has a method of the same name, in which case the class’s own method is step (1) and the mixin’s method is step (2). Understanding which step resolves the supermethod is the central diagnostic task when debugging dispatch chain bugs in ELENA mixin composition.

Generic handlers in ELENA provide a catch-all method body that receives any message not handled by a specific method declaration. A generic handler is declared with the generic keyword and receives the message name, arguments, and sender. Generic handlers are useful for delegation patterns, proxy objects, and dynamic message dispatch to wrapped objects. They are also a common source of dispatch bugs: when a class has a generic handler and a specific method is expected to handle a message, any misspelling of the method name, any mismatch in the Protocol binding, or any failure of the dispatch chain to reach the specific method will silently route the message to the generic handler, which may return a wrong result without signaling an error. The five wrong dispatch calls in the mixin bug were routed to the base singleton’s generic handler, which returned the singleton’s default value for unrecognized messages rather than raising an error, making the bug appear as wrong output rather than a crash.

ELENA mixin composition: method override chains, supermethod forwarding, and the composition order hazard

Mixins in ELENA are reusable method sets that can be composed into a class without requiring single-inheritance constraints. A mixin is declared with the mixin keyword and contains method declarations similar to a class. A class composes a mixin by listing it in the class’s composition clause: class MyClass : MyMixin, BaseClass { ... }. The mixin’s method declarations are merged into the class’s method table. When a message is dispatched to a MyClass instance, the runtime first checks MyClass’s own method declarations, then checks MyMixin’s methods, then checks BaseClass’s methods, in that order. The composition order matters: if both MyMixin and BaseClass declare a method for the same message, the mixin’s method takes precedence because it appears earlier in the composition clause. This is the override chain: the mixin overrides the base class for any message both respond to.

A supermethod call within a mixin method follows the composition chain from the mixin’s position. If MyMixin declares a method for message M and calls super M within that method, the runtime looks for the next handler for M in the composition chain after MyMixin’s position. In the chain [MyClass, MyMixin, BaseClass], the next handler after MyMixin is BaseClass’s method for M. The bug arose because the mixin developer expected the supermethod call to route to the Protocol method implementation on the base singleton, but the base singleton’s method table had a generic handler rather than a specific Protocol method implementation. The generic handler received the M message and returned the singleton’s default value rather than the Protocol-specified result. The developer expected the supermethod call to find a specific method; instead, it found a generic handler because the specific method was not declared at the position in the chain where the supermethod call resolved.

The explicit message forward pattern is the correct replacement for supermethod calls that depend on fragile composition-order assumptions. An explicit message forward sends a named message to a named target object: instead of super M, the mixin method calls target M, where target is an explicit reference to the object that should handle the message. This makes the dispatch target a named object rather than a position in the composition chain, which is resilient to composition order changes and to the insertion of new mixins between the calling mixin and its intended target. For the five-wrong-dispatch bug: the mixin method was restructured to hold an explicit reference to the Protocol implementor and forward the message directly, rather than relying on the supermethod chain to reach it. The dispatch became: mixin method receives message M → mixin method explicitly forwards to Protocol implementor → Protocol implementor’s specific method handles M → correct result. Wrong dispatch calls: 5/run → 0.

Singleton instances in ELENA are class instances created once and reused for all dispatch operations on that class. A singleton is declared with singleton and does not require instantiation: the singleton object is automatically created when the class is first referenced and is used for all subsequent message sends to that class. Singletons are common as Protocol implementors because they represent stateless behaviors — operations that depend only on their message arguments and not on per-instance state. The retainer work for singleton-based dispatch involves verifying that the singleton’s method table is correctly populated: that every Protocol method has a specific handler, that the generic handler (if any) is positioned correctly at the end of the dispatch chain, and that the singleton’s method implementations are correct for the full range of Protocol-specified messages. A singleton with a generic handler positioned before a specific method declaration is a common ordering bug: the generic handler captures all messages before the specific method can be reached, producing wrong dispatch for every Protocol-typed message.

ELENA class hierarchy, extension methods, module system, and the Alexei Rakov language design

ELENA’s class system distinguishes three primary class kinds: standard classes (reference types, allocated on the heap, with instance state and methods), sealed classes (reference types whose subclassing is prohibited, enabling the compiler to optimize dispatch to static binding), and value types (stack-allocated types with value semantics, similar to structs). Sealed classes are common for performance-critical types where the compiler’s ability to devirtualize dispatch is valuable; standard protocol-implementing service classes are typically unsealed to allow subclassing and mixin composition. The distinction between interface and Protocol in ELENA: both declare method signatures without implementations, but Protocol is ELENA’s primary abstraction mechanism used with dynamic dispatch, while interface has stricter static typing semantics. In ELENA 6.x, the practical distinction is that Protocol-typed variables use message-based dynamic dispatch while interface-typed variables use a more constrained static resolution.

Extension methods in ELENA allow adding methods to existing classes without modifying their source code. An extension method is declared in a separate module with the extension keyword, naming the class being extended and providing additional method bodies. Extension methods are visible only within the module where they are declared, unless the module is explicitly imported by callers. This module-scoped visibility is a common source of dispatch bugs: a caller in a different module sends a message that was intended to be handled by an extension method, but the extension is not imported, so the message falls through to the generic handler or raises a no-method error. The diagnostic question: is the extension method’s module in scope at the call site? If not, the fix is a using import declaration. Extension methods are ELENA’s primary mechanism for post-hoc Protocol conformance: adding Protocol conformance to a third-party class without modifying it requires declaring an extension method that implements the Protocol’s message signatures for the third-party class, then importing that extension at every call site where the third-party class is used as a Protocol target.

ELENA’s module system organizes source code into named compilation units. A module declares its name at the top of the source file and optionally imports other modules with using. The module system controls visibility of class declarations, singleton declarations, Protocol declarations, and extension methods. ELENA supports both source-level modules (compiled to ELENA bytecode) and binary modules (precompiled libraries). The ELENA standard library provides core modules: the base object model, primitive types (integers, floats, strings, collections), I/O streams, exception handling, and concurrency primitives. Alexei Rakov designed ELENA in 2004 and has developed it continuously since, with ELENA 6.x (current as of the mid-2020s) representing a significant redesign of the language core, bytecode VM, and standard library. ELENA’s design is motivated by the pure message model: unlike Smalltalk, which uses a similar model but compiles to an image-based VM, ELENA compiles to a native-code VM with ahead-of-time compilation, making it suitable for applications requiring predictable performance. ELENA’s closest conceptual relatives are Smalltalk (pure message model, image-based development) and Self (prototype-based OOP with message-based dispatch), but ELENA’s class-based mixin composition and ahead-of-time compilation distinguish it from both.

ELENA script and template meta-programming extend the language’s declarative capabilities. ELENA script allows declaring class structures and method bodies using a simplified syntax oriented toward configuration and data-driven generation. Templates generate class skeletons from parameterized patterns, reducing boilerplate in class hierarchies with many similar Protocol implementations. Retainer work on ELENA template meta-programming typically involves debugging generated class structures where a template parameter interaction produces a dispatch chain inconsistency not visible in the template source: the generated class has the wrong method in the wrong position in the dispatch chain, producing silent wrong-dispatch that only manifests when a specific Protocol message is sent to a generated-class instance. Diagnosing these bugs requires examining the generated bytecode or the generated class’s method table directly rather than reading the template source.

How HourTab tracks ELENA developer retainer hours

ELENA retainer work shares the invisible-work problem common to all message-based OOP retainers, compounded by ELENA’s dynamic dispatch model’s tendency to route wrong messages to generic handlers rather than raising errors, making bugs appear as wrong output rather than crashes. A mixin dispatch chain fix is a diff with a removed supermethod call and an added explicit message forward with a named target reference; the value is elimination of all wrong dispatch calls caused by the supermethod resolving to a generic handler instead of the intended specific Protocol method implementation, a correct understanding of how mixin composition order determines supermethod resolution, and an explicit forwarding discipline that is resilient to future composition order changes. An extension method visibility fix is a diff with one added using import declaration; the value is correct dispatch for all Protocol-typed message sends that depend on the extension, and a module import discipline that prevents the same silent no-method fallthrough from recurring when new call sites are added. A singleton method table audit that adds missing Protocol method implementations and repositions the generic handler is a diff with new method declarations and a reordered method table; the value is correct dispatch for all Protocol-typed messages to the singleton, elimination of silent wrong-result returns from the generic handler, and a singleton structure that matches the Protocol contract at every declared message.

HourTab gives ELENA developers a public retainer-hours URL they send to clients — typically research teams building experimental OOP systems based on ELENA’s pure message model, organizations that use ELENA for domain-specific language extensions, and groups exploring message-based dispatch architectures for systems that require the flexibility of late binding with the performance of native code — at the start of an engagement. For ELENA retainers, each work log entry should name the mechanism (Protocol interface declaration; class Protocol implementation; dynamic message dispatch analysis; message forwarding chain design; generic handler pattern; mixin composition; supermethod forwarding pattern; mixin method override chain; dispatch target identification; singleton instance declaration; extension method scope; module import and export), the specific classes, mixins, and Protocol methods involved in the bug, and the before/after metric. ELENA retainers are often compared to Smalltalk developer retainers for pure message-based OOP work and to Rebol developer retainers for language systems built on a small, uniform semantic core. HourTab’s work log makes the dispatch chain tracing, Protocol binding analysis, and message forwarding pattern redesign visible to clients who would otherwise see only the symptom — five wrong dispatch calls per run — and not understand why the fix required tracing the full mixin composition chain, identifying which supermethod call resolved to a generic handler, and restructuring the method to use an explicit message forward with a named target.

FAQ: ELENA developer retainers