Also begin populating values in the intermediate definition.
TODO: Replace the hack in the spec definition with something applicable
RDF-wise (is there anything that permits this RDF wise?).
- Fixed the way indexing nodes were being applied
- Implemented property types in ontologies
- Improved class types in ontologies
- Lots of other stuff
Also adds some placeholders for the schema ontology.
Eliminated some dead code in the RDF manager thing.
Next step is to get mainEntity parsing to ignore the rest of the values,
which should be easier to do, maybe.
Next, the actual nodes need to be created in order to construct the
proper intermediate form and translate the parsed data into a meaningful
structure that can be used to generate code.
Ideally, this could also potentially allow code generation in other
languages too. And different ways to read in ActivityStreams
specifications and extensions. But that would be way off in the future.
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.
