Implementations are relying more on each others' interfaces, which
allows for better code isolation and a better chance at pruning down
binaries when needed. Still plenty of TODO items left to tackle.
The manager class will be responsible for allowing the generated code to
be compilable while also permitting types and properties to be isolated,
such that binaries can be pruned to smaller sizes and not require the
entire gambit be built into the resulting executable.
This state will successfully generate code, but the generated code is
completely uncompilable. It will also trash the props/ directory.
This begins adding types as standalone compositions of properties, along
with helper functions to manage the hierarchy better than the current v0
implementation.
I think it will still need to be focused on flexibility at compile time
over runtime; but this will still allow extensions to be generated
easily from existing code.
This is a natural extension of the v0 philosophy: many folks still
cannot understand the similarity that to deploy new meaningful behaviors
with interpreted javascript/python/etc then code still needs to be
written and deployed, just as this go code will need to be regenerated,
written against, and deployed.
Code generation plus type system means a lot of the heavy lifting and
potential errors are already thought through for an ActivityPub
developer.