Array vs ElementArray?

[TeresiaOlsson]

@JeanLucPons I have a question so I don't break the code more than necessary when refactoring the config models.

Why in the arrays subpackage is there two versions of everything, e.g. bpm_array and bpm, cfm_magnet_array and cfm_magnet? What is the purpose of the two?

Looks to me like bpm_array has all the functionality whereas bpm doesn't do much except filling an ElementHolder?

[JeanLucPons]

Bassically you have the config classes (aggregate of string) and logic classes (aggregate of Element).
Then fill_array() create logic classes with Element from the holders.
i.e:
you can have only one array of string that can be extended to n array of element for each n holder.

[TeresiaOlsson]

Okay, then I understand that part. Now I'm wondering why there is a need to have arrays for different Element types? I imagined array to be a generic concept to group Elements without the need for specific implementation for different types?

What is the reason for the magnet_array, bpm_array, cfm_magnet_array and serialized_magnet_array? To me it feels like it is should be possible to make this generic so when you do set and get on an array it asynchronously calls the corresponding function on the Elements in the array. In ophyd-async there is a concept called DeviceVector which works like that and so far it has worked well in my tests.

If that is possible I think it would be a good idea since we then can reduce the number of modules to maintain. What do you think?