RFC: Future of IsMatrix traits / Providing a better alternative
There's a class named
IsMatrix<M>::value defaulting to
false but specialised so that
IsMatrix<DenseMatrix<T> >::value = true; IsMatrixstruct<BCRSMatrix<T,A> >::value = true;
Within the core modules, this traits class is only used by
dune/istl/matrixmarket.hh. It looks rather old (e.g. because it uses explicit enums instead of inheriting from
std::true_type) and since it covers so few Matrix types its utility is rather limited.
IsMatrix<DiagonalMatrix<...>>::value should be false, which is rather annoying. So maybe the class will go the way of the dodo at some point.
At the same time, it would be rather desirable to have such a traits class and it would be nice to have it in the core modules. Here's why: If everybody has to write such a class in his/her own module, that's annoying. So let's move it up a bit, say you'd have such a thing in a module everybody in your working group/team is using. A
MultiTypeBlockMatrix is obviously a matrix and if somebody in your group uses it, the header for the traits class will have to
#include <dune/istl/multitypeblockmatrix.hh>. But maybe you don't. So now by including the header of the traits class you get that matrix header included unnecessarily (the full picture: the header for the traits class will have to
#include the header for each matrix that it's supposed to support). So instead, it would be nice if the
MultiTypeBlockMatrix specialisation of the traits class was contained in
dune/istl/multitypeblockmatrix.hh itself (full picture: the arrows point the other way. each matrix class
#includes the tiny traits header). But that's only possible if the traits class lives in one of the core modules, or more precisely
So with these two sets of thoughts out there: I think it would be nice to have a matrix traits class header like
dune/common/ismatrix.hh and have every matrix out there do the include-and-specialise dance. The current
IsMatrix could be deprecated and replaced. Writing the code is trivial and I'd volunteer to do it; I'm interested in whether this is superfluous or a stupid idea somehow, though.
My motivation is: Such logic is needed in the
dune-matrix-vector module. Consequently, there's a traits class in that module and it follows the approach where "the arrows point in the wrong direction", i.e.: this one header includes the header for every supported matrix class. I'm looking for a better solution that serves everyone here.