You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
With #1392 adding
RegisterabletoMultiUseSandbox, the split betweenUninitializedSandboxandMultiUseSandboxis increasingly hard to justify. Two changes could simplify the API:UninitializedSandbox::from_snapshot() → evolve() → MultiUseSandbox. If the snapshot path handled init directly and produced aSandbox(orMultiUseSandbox) in one step, the two-phase flow could collapse and the uninitialized state becomes an internal detail rather than a user-facing type.HostFunctionRegistry: Instead of registering host functions directly on the sandbox (as feat(host): implement Registerable for MultiUseSandbox #1392 does today via theRegisterabletrait), 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 currentRegisterabletrait approach. (Note: internally aFunctionRegistryalready exists — this would promote and reshape it into a public-facing API.)