Create AttributeVector class similar to ControllerVector, but storing a set of Attribute by non-contiguous index. This will map onto DeviceVector[Signal] in ophyd-async. In contract to ControllerVector in that it does not implement Attribute, it is purely a Mapping[int, Attribute] for convenience.
As AttributeVector is not Attribute, there will have to be a BaseController.add_attribute_vector and add a case for it in __setattr__. Then the creation of the Controller_API should unpack these into the flat list of Attribute.
Create an Attribute_T type var bound to Attribute and use as the Generic type for AttributeVector. This typing will not encapsulate access mode or datatype to ensure correct use because this would be difficult to define properly. Instead users will just get what they pass in. For example, AttributeVector({1: AttrR(Int()), 2: AttrW(String())}) would not provide any helpful type safety when accessing the vector, so this should not be done.
Create
AttributeVectorclass similar toControllerVector, but storing a set ofAttributeby non-contiguous index. This will map ontoDeviceVector[Signal]in ophyd-async. In contract toControllerVectorin that it does not implementAttribute, it is purely aMapping[int, Attribute]for convenience.As
AttributeVectoris notAttribute, there will have to be aBaseController.add_attribute_vectorand add a case for it in__setattr__. Then the creation of theController_APIshould unpack these into the flat list ofAttribute.Create an
Attribute_Ttype var bound toAttributeand use as the Generic type forAttributeVector. This typing will not encapsulate access mode or datatype to ensure correct use because this would be difficult to define properly. Instead users will just get what they pass in. For example,AttributeVector({1: AttrR(Int()), 2: AttrW(String())})would not provide any helpful type safety when accessing the vector, so this should not be done.