Status: To Do
Fix Version/s: None
Team:Data Release Production
This ticket captures some concerns I noticed in the BoundField classes while working on
DM-22069; they're absolutely out of scope for that ticket, and probably not high-priority overall, but it's worth writing them down now:
- All of the tests for the BoundedField base class are in the tests for ChebyshevBoundedField, which made sense back when it was the only concrete subclass, but doesn't make sense now. We should have a test mixin for all BoundedFields that tests base-class invariants (e.g. persistence round-tripping) and some utilities for testing derived-class implementations.
- There's really no need to expose most concrete derived classes directly, either in C++ headers or via pybind11 bindings. After construction, most (all?) concrete BoundedField classes are used exclusively through the base class interface, and that means we could just be exposing factory functions in headers and Python. That would save on both compile time and Python import time.
- The interpolation logic in the BoundedField base class is super complex and doesn't interact with the vectorized evaluation API in large part because it tries really hard to avoid temporary memory allocation. I'm not sure that's a good tradeoff; we should at least make the interpolated logic call the vectorized evaluation method.