Implementations are relying more on each others' interfaces, which
allows for better code isolation and a better chance at pruning down
binaries when needed. Still plenty of TODO items left to tackle.
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.
This setup allows properties to recur deserializing into types as
necessary, and sets the groundwork for successfully handling all kinds
of JSON-LD input.
Right now the two-pass tooling system has issues with establishing
doubly-linked data between Functiona/NonFunctional Properties (which
have Kinds abstractions) and Types (which have Property abstraction).
While the experimental tool compiles, it panics at runtime currently
because the TypeGenerator needs to look at properties with Range of
itself, but it is applying itself to properties with Domain of its type.
Which is wrong.
Will need to stew on this and think of how to avoid making even more
shortcuts and hacky solutions in the name of progress.
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).
- Prepared Types to be Kinds.
- Need to handle DoesNotApplyTo (to remove Intransitive properties from
parent)
- Need to handle crafting files in the appropriate structure.
Still need to flesh out the types for conversion. Also still need to add
the serialize and deserialize calls for individual types. Finally, will
need to put the finishing touches on writing the output files in the
desired directories. Then the experimental tool will be ready for end to
end testing.
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.
Cory Slep