You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The various create_<hardware>_from_config scripts are currently also capable of creating a "simulator" version of the hardware. To me that seems non-logical as creating from config should necessarily be creating real hardware.
Describe the solution you'd like
I would propose we remove all simulator creation from these convenience functions and handle simulator creation separately. This could look like a create_from_config (one name for each type of hardware, specified as a class method on the base class) and create_simulator.
Additional context
I think this would help with testing, both for software testing as well as real hardware testing.
I'm concerned about this proposal because I don't want the production code to have branches such as "if should use simulator". I'm wondering if we can't have a third method: create__driver, which is used by the production code, and is responsible for deciding if we're using a hardware driver simulator or a real driver (possibly with simulated hardware).
I discussed the above with @ImmortalRabbit this morning, and noted that this would mean we'd have a repeated pattern for each type of hardware. This lead me to wonder about some common approach to this, such as an application of the Registry pattern. Thoughts?
The various
create_<hardware>_from_config
scripts are currently also capable of creating a "simulator" version of the hardware. To me that seems non-logical as creating from config should necessarily be creating real hardware.Describe the solution you'd like
I would propose we remove all simulator creation from these convenience functions and handle simulator creation separately. This could look like a
create_from_config
(one name for each type of hardware, specified as a class method on the base class) andcreate_simulator
.Additional context
I think this would help with testing, both for software testing as well as real hardware testing.
Related Issues/PRs
#848 #636 #849 #478 #29 #842 #843 probably more.
Thoughts? @jamessynge @ImmortalRabbit @AnthonyHorton
The text was updated successfully, but these errors were encountered: