This change is quite signficant, and requires that TranslationLayers
get all additional parameters that they need through their requirements.
These are now automatically enumerated and populated on object
construction based on the requirements, so should not require lots of
repetitive filling out of fields.
It does come with the downside that TranslationLayers can only be
contructed with a context (and appropiate config), but TLs in particular
always require a context (to contain the base layer) and blank configs
can be constructed relatively easily (convenience functions can be added
if necessary).
This allows configuration trees to be built up, and their configs
spliced into an existing config (as if it were being loaded from a
file).
Not all ConstructableRequirements use this method, since SymbolTables
(for example) do not have access to the context or config_path in order
to get to any parameters stored in the context's config. They therefore
are still passed their requirement values as __init__ parameters
instead.
commit fbf5eb6309
Author: Mike Auty <mike.auty@gmail.com>
Date: Sat Aug 20 13:21:47 2016 +0100
Remove other unnecessary files and drop the templates, but use the static files.
commit 2bf92be628
Author: Mike Auty <mike.auty@gmail.com>
Date: Sat Aug 20 13:10:20 2016 +0100
Remove unnecessary elements imported with the python3 doc theme.
commit 31b6d84e58
Author: Mike Auty <mike.auty@gmail.com>
Date: Sat Aug 20 12:07:08 2016 +0100
Add in python3 documentation theme files and convert to using those.
This also adds support for manually constructed configurables to
populate the config tree in the current context.
I'm still toying around with this though, I need to figure out
what to do with optional values and think the whole thing through
to make sure it's worthwhile.
This one's slightly contencious, in that scanner now don't all return a
uniform value, and therefore nothing can simply run through scanners.
Worst case scenario we make a separate stricter interface that says it
only returns offsets which will then allow things that need it to
dynamically find them, but it's probably too useful to be able to return
arbitrary objects of a type (as long as the objects returned are always
of that type).
Mike Auty