This allows SymbolTables to hold actual requirements (which
IntermedSymbolTable already did, but without pulling in the right
interface). It means that values like kernel_virtual_offset get saved.
We still need to figure out how to allow plugins to demand optional
configuration values in other places (such as the kvo) but for now the
plugin will barf if it doesn't get it.
This template type allows objects that have not been able to be resolved
to exist within the symbol system. It emits a debug message on creation
so that intermediate format developers can identify potential issues,
but does not raise an exception so as to allow partial tables to be
used.
If the UnresolvedTemplate is called (to create an object) before the
symbol has been added to the symbolspace, it will fail with a
SymbolError (as thrown by the individual SymbolTable). For this reason,
the class has been made private to the SymbolSpace class to prevent
unexpected use.
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.
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).
So this is where I ripped out the guts of the dependency tree
and made it a little better defined in some ways, and delayed
populating it in others. The validate function signature has
changed and I'm still up in the air whether to validate with
True/False or throw/catch exceptions.
So now, configurables have a list of requirements, these are
then bundled into a single requirement and can be passed to
automagic. Automagic runs a set of things over the deptree
to help build/manage it. These run in order of priority.
The tree is still built from the top down, but now automagic
can build branch from the bottom up and try and splice them
into the tree where appropriate. Hopefully this will make it
easier to see follow.
Mike Auty