Open daniel-thom opened 4 years ago
My understanding of this proposal is that we are
@daniel-thom feel free to correct me if I'm misinterpreting or omitting certain pieces.
From talking with Dheepak I don't think it will be practical to remove storage of the Store
in the Line
(or other component). What we could do as an intermediate step is remove that attachment in the Line
constructor. The main reader could still perform this attachment so that the final behavior is the same. That could make it easier to take the next step in the future.
This still could be bad for two reasons:
list
function was complete. Something might need that reference. You guys mentioned that there are two scenarios when converting a component to ditto: 1) information is self-contained and can be directly converted, 2) you have to combine information from multiple components to convert one component. That second case might require access to the model.Just as a comment, I think the code would be easier to reason about if the Store
was only modified in ditto/store.py
.
This integrates the datamodel that Dheepak created with a proposal for a new common reader.
The main new concept here is this:
ditto.readers.reader.DiTToReader
is responsible for controlling the parsing process.DiTToReader
creates a reader interface for the simulation engine specified by the inputs.ditto.readers.reader_interface.ReaderInterface
specifies the required methods for a reader.I think this design would be better if the
Store
object was not stored within each DiTTo model instance. I'm OK with keeping it like this.