Skip to content

Unify sandbox types: initialize directly from snapshot and introduce HostFunctionRegistry #1402

@danbugs

Description

@danbugs

With #1392 adding Registerable to MultiUseSandbox, the split between UninitializedSandbox and MultiUseSandbox is increasingly hard to justify. Two changes could simplify the API:

  • Move initialization into snapshot loading: Today, loading from a snapshot still goes through UninitializedSandbox::from_snapshot() → evolve() → MultiUseSandbox. If the snapshot path handled init directly and produced a Sandbox (or MultiUseSandbox) in one step, the two-phase flow could collapse and the uninitialized state becomes an internal detail rather than a user-facing type.
  • Introduce a HostFunctionRegistry: Instead of registering host functions directly on the sandbox (as feat(host): implement Registerable for MultiUseSandbox #1392 does today via the Registerable trait), a standalone registry object could be built up front and validated against the signatures the snapshot expects before the sandbox is created. This gives early type-checking and cleaner separation of concerns, replacing the current Registerable trait approach. (Note: internally a FunctionRegistry already exists — this would promote and reshape it into a public-facing API.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    lifecycle/confirmedBug is verified or proposal seems reasonable

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions