- 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.
This is on the road for v1: enabling plugins for vocabulary extensions
and either supporting them in static or dynamic scenarios.
This new as/ folder is temporary to play around with, it is expected to
fold back into the pub area once I am making more sweeping changes for v1.
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.
The 'liked', 'likes', 'followers', and 'following' collections now
default to the 'OrderedCollection' type instead of throwing an error if
the client application does not supply an IRI, 'Collection', or
'OrderedCollection' type on the actor or object.
When deduplicating IRIs in a user's inbox, the library tries to
dereference the IRI to... obtain the ID. I must have added this when I
had no idea what I was doing. Oh my god, everyone's going to know I am
dumb! Quick, don't read this commit message, I'll just finish typing
this sentence over here.
Well, it's fixed now.
