Trait ComponentExec 

pub trait ComponentExec {
    // Required method
    fn exec(
        &mut self,
        component: &str,
        ports: &[(String, Value)],
        bound: Option<&Value>,
    ) -> Option<ExecOutcome>;

    // Provided method
    fn exec_ctx(
        &mut self,
        node_id: &str,
        component: &str,
        ports: &[(String, Value)],
        bound: Option<&Value>,
    ) -> Option<ExecOutcome> { ... }
}

The boundary-injected handler registry seam (§7.1). Resolves a catalog name to a leaf implementation and executes it with evaluated ports (+ the map element bound value, if any). Returns None when the name is unknown so run_behavior can fail closed with UNKNOWN_COMPONENT.

Required Methods

fn exec( &mut self, component: &str, ports: &[(String, Value)], bound: Option<&Value>, ) -> Option<ExecOutcome>

Provided Methods

fn exec_ctx( &mut self, node_id: &str, component: &str, ports: &[(String, Value)], bound: Option<&Value>, ) -> Option<ExecOutcome>

behaviorVersion 2: like ComponentExec::exec but carrying the handler ctx (node_id = body node id, component = catalog name). run_behavior calls this seam for every handler invocation. The default forwards to exec, so existing implementations keep working unchanged; override it to observe the node identity (error context / tracing).

Trait Implementations

impl ComponentExec for &mut dyn ComponentExec

Blanket forwarding impl so a trait object handler registry (&mut dyn ComponentExec) itself satisfies ComponentExec (bc#68).

The generic straight-line / typed codegen surface exposes generic-by-value entries (bind<H: ComponentExec>(handlers: H) / run_*<H: ComponentExec>( handlers: &mut H, …)). A consumer that holds its handler registry behind a trait object (handlers: &mut dyn ComponentExec — exactly how run_behavior takes it) could not name a concrete H to hand those entries. This impl makes H = &mut dyn ComponentExec a valid instantiation, so the trait-object handler drives the generated straight-line/typed module through the unchanged generic path (no bind_dyn variant needed, no emitter change). It is purely additive: every existing concrete H keeps working exactly as before.

Both methods forward to the underlying dyn (a plain reborrow), so calling a generated module through &mut dyn runs the SAME straight-line/typed code as a concrete handler — it never falls back to run_behavior.

fn exec( &mut self, component: &str, ports: &[(String, Value)], bound: Option<&Value>, ) -> Option<ExecOutcome>

fn exec_ctx( &mut self, node_id: &str, component: &str, ports: &[(String, Value)], bound: Option<&Value>, ) -> Option<ExecOutcome>

behaviorVersion 2: like ComponentExec::exec but carrying the handler ctx (node_id = body node id, component = catalog name). run_behavior calls this seam for every handler invocation. The default forwards to exec, so existing implementations keep working unchanged; override it to observe the node identity (error context / tracing).

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors

impl ComponentExec for &mut dyn ComponentExec

Blanket forwarding impl so a trait object handler registry (&mut dyn ComponentExec) itself satisfies ComponentExec (bc#68).

The generic straight-line / typed codegen surface exposes generic-by-value entries (bind<H: ComponentExec>(handlers: H) / run_*<H: ComponentExec>( handlers: &mut H, …)). A consumer that holds its handler registry behind a trait object (handlers: &mut dyn ComponentExec — exactly how run_behavior takes it) could not name a concrete H to hand those entries. This impl makes H = &mut dyn ComponentExec a valid instantiation, so the trait-object handler drives the generated straight-line/typed module through the unchanged generic path (no bind_dyn variant needed, no emitter change). It is purely additive: every existing concrete H keeps working exactly as before.

Both methods forward to the underlying dyn (a plain reborrow), so calling a generated module through &mut dyn runs the SAME straight-line/typed code as a concrete handler — it never falls back to run_behavior.