Expose inner off-design problem of systems?
Description
The inner, off-design problem of a system is stored with "protected" attribute _math
(protected in the Python sense "you can access it, but are not supposed to").
The rationale for keeping attribute _math
semi-private was that users are not supposed to meddle with the inner off-design problem, defined exclusively at setup via methods System.add_equation
and add_unknown
.
This picture is questioned with the possibility to modify a system behaviour during event-driven transitions.
At present, users can add many things (children, equations, connectors, etc.), but can hardly remove anything (pop_child
being a notable exception).
This calls for an API change.
One easy solution would be to expose System._math
via a property problem
, say.
This would conveniently allow users to code things like
class MultimodeSystem(System):
def setup(self)
# whatever
self.add_event('kaboom')
def transition(self):
if self.kaboom.present:
self.problem.unknowns.clear() # for example
self.add_unknown('x')
# whatever
without having to add a gazilion new methods like System.clear_unknows()
, clear_equations()
, pop_unknown(name)
, and so on.
The downside is that it opens the door to dangerous usage, such as:
s = SomeSystem('s')
s.problem.clear() # should be forgiven!
The latter could be made impossible through a locking mechanism, as already done for add_equation
and add_unknown
, among others.
The thing is it would be less trivial, since it would require a locking mechanism on a MathematicalProblem
object based upon the status of its owner.
The logical pattern would be to use a MathematicalProblem
proxy, akin to what is done to make connectors switchable within systems, without affecting class Connector
, or any user-defined connector class.
I am inclined to go down this road. What do you guys think? @All