This is a non-traditional brainstorming RFC to gather preliminary input prior to design work. The (mostly-)completed design will be RFC'd separately in the future (and I'm not even planning to start that work for several weeks).
My goal is to replace afw::image::Filter with something that:
- minimizes the use of singletons;
- maps to the Gen3 PhysicalFilter and AbstractFilter concepts (probably with separate classes for these);
- has a sensible relationship with cameraGeom (probably just "Camera has a set of PhysicalFilters");
- has a sensible relationship with TransmissionCurve (not obvious; could be "PhysicalFilter has TransmissionCurve" or "PhysicalFilter can be used to retrieve a TransmissionCurve from a calibration repo");
- can be easily mangled into deterministic integer IDs without addition or subtraction of filters breaking old IDs;
- natively supports or can be extended to support sub-filters for DCR-correctable coadds.
More use cases and design ideas welcome.
Jim Bosch, in DMCCB#4 discussion, this RFC has been proposed to be withdrawn, since it is just speculative and not triggering any action.
Fine; I think I've gathered the information I was going to and will return with an actual proposal in a new RFC.
(I will say, however, that this was useful, and I hope we will not discourage open-ended RFCs like this in the future without providing an alternative - though maybe that's just a community post).
Hi Jim Bosch — I think it's fair to say the DMCCB's position on this was effectively that RFCs are a tool for taking decisions, rather than soliciting open-ended discussions; we'd imagine that CLO would be more appropriate for the latter. I'd be happy to receive thoughts and feedback about whether a CLO post would have got you the results you want in this particular case, and, if not, what we might do about it.
Pushing this out some more. I have thought a bit about a more concrete proposal and plan to make one, but it's not terribly close to the top of a rather long to-do list.