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.
The sub-types of Intransitive Activity (Arrive, etc) would not satisfy
the vocab.IntransitiveActivityType interface, due to not accounting for
the parent WithoutProperties definition.
This fixes that code generation, so that all Activity subtypes will be
able to be properly converted to vocab.ActivityType or
vocab.IntransitiveActivityType.
Updated the PostOutbox code path to properly handle this distinction
when receiving a C2S IntransitiveActivity.
The IsPublic method will return 'true' if the special public collection
defined in the ActivityPub spec is addressed in the 'to', 'bto' 'cc', or
'bcc' properties of the Object or any of the types extending from them.
This condenses the N types and M properties from N*M intermediate type
definitions to just M intermediate type definitions. These intermediate
types are no longer generated in the gen_<TYPE>.go files, but are all
within the separate gen_intermediate.go file.
This will hopefully reduce resource consumption during compilation of
the vocab package.
This helps ensure that the code to detect specific ActivityStream types
continues to live in the code-generation algorithms, reducing
maintenance burdens.
He who fights with monsters should be careful lest he thereby become a monster.
And if thou gaze long into an abyss, the abyss will also gaze into thee.
