The TableColumn trait suffers from limitations:
- it is not dyn-compatible
- the create relies on returning an opaque type implementing the trait
These two points collaborate to make it difficult (impossible?) to do
things like write functions that return aggregations of columns.
(In another project, I tried to write such a function to reduce code duplication...)
It seems that attempting type erasure led to an API that is too limited.
This corner of the code should probably be refactored to:
- Use concrete types. (Doing so will require PhantomData for the row index type...)
- Apply a sealed trait indicating that our row id newtypes are row index types.
This is API-breaking but we can probably do some of the back end w/o breaking things.
The TableColumn trait suffers from limitations:
These two points collaborate to make it difficult (impossible?) to do
things like write functions that return aggregations of columns.
(In another project, I tried to write such a function to reduce code duplication...)
It seems that attempting type erasure led to an API that is too limited.
This corner of the code should probably be refactored to:
This is API-breaking but we can probably do some of the back end w/o breaking things.