Device ADR proposal

[coretl]

No description provided.

[Tom-Willemsen]

Some thoughts from office conversations at ISIS (@rerpha):

• We feel the procedural option is nicer / more supportable / less magical (basically in agreement with ADR 6)
• In most of our cases we probably could write our devices using the declarative approach, but in a few places it would probably get a bit messy and much harder to read than the procedural approach
  • Slightly worried about loss of flexibility / explicitness
• How would a type-generic device be written using the declarative approach? If I have a Generic[T] device would the T typevar be a valid datatype to pass to the declarative signal datatype? I'm a bit worried about getting tied in typing knots here and it's all very not-obvious I feel, whereas the explicit approach makes it quite obvious...

Would appreciate being involved in the discussion if it looks like we might be going towards declarative route.

[coretl]

One key point that came out of the discussion is that we should always be free to drop to procedural. We should always be able to have an __init__ method that does epics_signal_rw calls. This should be used for any of the DeviceVector cases, and any tricky generics (although I think they could mostly be made to work in the declarative approach). This means we should never be writing a formatted string in the declarative approach, if we need it we should drop to an __init__ method.

The question here is should we support the declarative approach for a subset of the EPICS devices. I think the large number of areaDetector drivers and plugins we are writing are good use case for this, they have no logic, only interface, and are more naturally written in the declarative style. This would allow us to teach the declarative style first, then introduce the procedural style when we need the more complicated examples.

Happy to discuss this in more detail on a zoom call

[Tom-Willemsen]

@coretl and I discussed on zoom but will add the result of the discussion here:

One key point that came out of the discussion is that we should always be free to drop to procedural.

This is fine from our perspective then - I was worried that the annotation style would be enforced, as long as procedural is still a supported option this is fine for us.

[DominicOram]

I echo @Tom-Willemsen's thoughts. Prefer the more explicit procedural approach but happy if ophyd_async supports both. Could I suggest we add a line in the ADR that explicitly says something like "This is not a step towards only supporting the declarative approach and there are no plans to drop the procedural approach"