Description, motivation and use case
ElementHolder stores every element for a control mode, but its public API still requires callers to know whether an object is an individual element or a configured array. The typed holders cover magnets and BPMs, but users cannot yet browse all elements through one consistent collection interface.
This matters for interactive workflows that start from a mode and need to select elements by name before applying existing array operations.
Proposed solution
Add a generic public collection API to ElementHolder:
holder.get() returns all attached elements as an ElementArray.holder[:] is equivalent to holder.get().holder[pattern] selects elements by name wildcard and returns the most specific compatible array type.
Keep get_element() and get_elements() unchanged for backward compatibility. Exact configured-array lookup remains available through get_elements(name); the new API is for generic collection navigation.
Describe alternatives you've considered
Keeping only get_element() and get_elements() preserves the current API, but requires callers to decide in advance whether they need a singleton or an array. Exposing the internal _ALL mapping would avoid new methods but would leak implementation details and bypass typed array behavior.
Example
all_elements = sr.live.get()
same_elements = sr.live[:]
bpms = sr.live["BPM*"]
cell_elements = sr.live.get_elements("CELL08")
cell_magnets = sr.live.magnets[:] & cell_elementsAdditional context
Parent issue: ElementHolder API refurbishment #199.
ElementArray already provides slicing, wildcard selection, and set-like operations. Domain-specific field filtering remains the responsibility of typed arrays; for example, model_name is a magnet-specific field.
Checklist
Description, motivation and use case
ElementHolderstores every element for a control mode, but its public API still requires callers to know whether an object is an individual element or a configured array. The typed holders cover magnets and BPMs, but users cannot yet browse all elements through one consistent collection interface.This matters for interactive workflows that start from a mode and need to select elements by name before applying existing array operations.
Proposed solution
Add a generic public collection API to
ElementHolder:holder.get()returns all attached elements as anElementArray.holder[:]is equivalent toholder.get().holder[pattern]selects elements by name wildcard and returns the most specific compatible array type.Keep
get_element()andget_elements()unchanged for backward compatibility. Exact configured-array lookup remains available throughget_elements(name); the new API is for generic collection navigation.Describe alternatives you've considered
Keeping only
get_element()andget_elements()preserves the current API, but requires callers to decide in advance whether they need a singleton or an array. Exposing the internal_ALLmapping would avoid new methods but would leak implementation details and bypass typed array behavior.Example
Additional context
Parent issue: ElementHolder API refurbishment #199.
ElementArrayalready provides slicing, wildcard selection, and set-like operations. Domain-specific field filtering remains the responsibility of typed arrays; for example,model_nameis a magnet-specific field.Checklist