Description
Is your feature request related to a use case or problem? Please explain
Parameterization requires a bunch of boilerplate (_is_parameterized_, _parameter_names_, _resolve_parameters_, all of which just check / replace the specified member variables). It seems like something a decorator could handle well.
Describe the solution you would prefer
It'd be great if in #5985, the solution could just be "add the decorator to QasmUGate", something like
@parameterizable("theta", "phi", "lmda")
class QasmUGate(ops.Gate):How urgent is this for you? Is it blocking important work?
P3 – I'm not really blocked by it; it's an idea I'm proposing based on principle
Process Note
For anyone wanting to take this issue, it's probably worth a mini RFC and finding a maintainer (not me) to sponsor it before starting work (assuming this even gets to triage/accepted state). While it's probably below the "RFC Required" bar, I think there are enough variables, that having an approved design would be beneficial. (Some things that come to mind: What happens if only some fields are parameterizable? Can/should it work both with dataclasses and with non-dataclasses? Can the implementations be overridden in classes it's applied to? How to apply it in gate class hierarchies (e.g. at the EigenGate level or at each subtype?) Does it interact with mypy typing in any way or are type declarations independent? What's the best way to test it? Is it worth going back and retrofitting existing gates into this model?)