This is an evolution of the old tools/defs/types.go file which
essentially had these data structs manually defined in a static go file.
Now, the parser should be able to construct this data structure on the
fly from input files and reference files.
This package will be the frontend for reading the JSONLD context
descriptions that specify ActivityStreams vocabularies. This will allow
ingesting publicly hosted or manually-created vocabularies and
generating an internal representation for later code generation.
- 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.
After deliberating on the APIs for properties that can have a single
type vs multiple types, I've decided to keep the distinctly separate
APIs for the single-type properties. This means humans reading the APIs
will use simpler and more reasonable getters/setters, etc. However, by
default the two kinds of properties will not be able to satisfy the same
interface.
If this is needed, in the future we can auto-generate thin-wrapper types
around single-type properties that cause them to have a shared API with
the multi-type properties. But that won't be tackled for now, as its
expected use case is small.
