Also write interfaces into public sections.
Lots of TODOs and more work to add.
Will need to look into how to simplify this logic -- there is a lot of
redundancy and kludgy-feeling things. Will definitely need to address
the converter part as it is very redundant.
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.
Still plenty of missing features, and missing implementations in the
generated code. Also missing some functionality and flags for generating
references and/or well-known references (ex: XML, RDF values).
- Fixed extendedBy generated method behaving like extends
- Add the extends generated method
- Extends / extendedBy examine the parent / children as well
- Properties and types cache their generated structs, only creating the
codegen types once
- Create convenience constructor methods
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.
Cory Slep