Make access methods for multiple dofmaps/cmaps/elements etc. more consistent

[chrisrichardson]

Currently, for the new "mixed-topology" functionality, we have new functions to access the multiple entries, e.g.
to access the i component:
Geometry::cmaps()[i], Geometry::dofmap(i), FunctionSpace::elements(i), FunctionSpace::dofmaps(i), Topology::cell_types()[i], Topology::original_cell_index[i]

There may be more... but they all look different. What is the best interface?

[chrisrichardson]

See #4169

[chrisrichardson]

Now working on geometry dofmap in #4173

[chrisrichardson]

What should the interface look like in C++ vs Python?
Currently aiming towards something like geometry.dofmap(i) for both... but maybe better as a list in both?
e.g. returns geometry.dofmap() returns std::vector<DofMap> in C++, and a property in Python (so could be accessed like geometry.dofmap[0] for the first one...

[jhale]

My two cents; it's better to expose the iterable (std::vector, list/Sequence?) as presumably the caller is going to want to iterate over these things?

[chrisrichardson]

In Python, do we want to retain e.g. geom.dofmap for single access (as now) and geom.dofmaps[i] for multiples or force users to go for geom.dofmaps[0] (or geom.dofmap[0]) for single? My feeling is we should just have one interface.

[michalhabera]

I would keep geom.dofmap as a convenience property for the single-dofmap case. If there is exactly one dofmap, it returns it. If there are multiple, it raises and tells the user to use geom.dofmaps instead.

Then geom.dofmaps can be the canonical general interface, exposed as a list/sequence from the nanobind std::vector binding.

This is backward compatible, ergonomic for the common case, and still makes the multiple-dofmap case explicit rather than silently choosing one.

[jhale]

I would prefer to add geom.dofmaps[i] and then retain and deprecate geom.dofmap (also with the throw as Michal suggests).