Working towards #6146, likely to be split into multiple PRs for sanity.
This aims to be a purely cleanup/refactoring PR with minimal semantic impact:
Renaming wrap.h to context.h, moving implementation entirely to context.cpp
Moving many free functions to be members of Context, to aid discoverability and clarify dependencies
Moving population/insertion of globals (ie - the ccf. object accessible in JS) to separate files, so we can work out which should eventually be public, and/or extensible samples
Next steps, to be split across this PR and others depending on merge speed:
[x] Add a few more sensible methods to Context so we have fewer users of the jsctx.wrap() escape hatch
[ ] Split Context into a plausible hierarchy - pure wrappers around QuickJS, extensions with our module loading and caching, extensions to insert our globals, extensions with our governance-specific globals
[ ] Rename Context to Interpreter? Potentially Runtime. We currently have a Runtime and Context mapping directly to the QuickJS equivalent types, but I think we should break that binding and make our own names
Working towards #6146, likely to be split into multiple PRs for sanity.
This aims to be a purely cleanup/refactoring PR with minimal semantic impact:
wrap.htocontext.h, moving implementation entirely tocontext.cppContext, to aid discoverability and clarify dependenciesccf.object accessible in JS) to separate files, so we can work out which should eventually be public, and/or extensible samplesNext steps, to be split across this PR and others depending on merge speed:
Contextso we have fewer users of thejsctx.wrap()escape hatchContextinto a plausible hierarchy - pure wrappers around QuickJS, extensions with our module loading and caching, extensions to insert our globals, extensions with our governance-specific globalsContexttoInterpreter? PotentiallyRuntime. We currently have aRuntimeandContextmapping directly to the QuickJS equivalent types, but I think we should break that binding and make our own names