Open tclune opened 2 months ago
There may be a dependency chain:
mapl3g_VariableSpec
depends on mapl3g_StateItemSpec
and mapl3g_FieldSpec
which in turn depends on mapl3g_StateIemSpec
, currently.VariableSpec
to pass itself into FieldSpec
in the constructor called from make_itemSpec
FieldSpec
needs a VariableSpec
argument.mapl3g_FieldSpec
needs to depend on mapl3g_VariableSpec
.Is that correct? I can work around it, but I want to confirm:
mapl3g_StateItemSpec
to depend on mapl3g_VariableSpec
.FieldSpec
objects after they are constructed.I think this:
- field_spec = FieldSpec(variable_spec) ... call field_spec(_RC)
should be this:
field_spec = FieldSpec(variable_spec) ... call field_spec%initialize(_RC)
I think this:
- field_spec = FieldSpec(variable_spec) ... call field_spec(_RC)
should be this:
field_spec = FieldSpec(variable_spec) ... call field_spec%initialize(_RC)
Yes. Sorry.
For indirect reasons, it would now be preferable if subclasses of StateItemSpec have trivial constructors with an initialize() method doing more of the heavy lifting.
This could be done in two ways: (Consider FieldSpec is the poster child for StateItemSpec subclasses)
Originally I was thinking (1), but (2) has several advantages. In particular, it means that VariableSpec does not appear in the interfaces of StateItemSpec, and this may allow
make_ItemSpec()
to continue to live right where it is and require less total refactoring.For now the call to initialize() can remain inside of
make_ItemSpec()
. Moving that to a new home is something I can do when I'm ready to exercise this functionality.I will need this soon, so please be honest about level of effort you can apply.