MeshPickling
I re-encountered ticket:313 and realized that my fix (r4018) had been overwritten by James' mesh refactorpalooza (r4080).
The immediate fix is to reapply r4018 by introducing a `` to `Gmsh2D`, doing the same for `Gmsh3D` (which I'd missed before), and to introduce appropriate test cases. Done: r4191.
This fix is sort of gross, because what you end up with is not really a `Gmsh2D`/`Gmsh3D`, but a `Mesh2D`/`Mesh` that has the appropriate vertices/faces/cells. That's almost(?) always all you want, but it's still not very clean from a class architecture standpoint. From what we've been pickling, we couldn't regenerate `mshFile` even if we wanted to, and we almost certainly don't want to. There's no guarantee that Gmsh would regenerate the same mesh from the inputs, and so restart/post-analysis would fail.
All of this points to the idea that most of our `Mesh` classes should actually be factories. Once I have the mesh, do I really care whether it was generated by Gmsh or assembled as a `GapFillMesh`? Almost certainly not. Those are tools for mesh generation. The mesh itself cares only about its geometry and topology, which James has now factored out more cleanly.
Q: If meshes are refactored into a bunch of factory functions/classes, can we still unpickle old meshes? Answer better be yes.
In the course of looking into a better fix for ticket:313, I realized that we're almost certainly using `` and `` incorrectly. In many cases, all we do is some variant on:
with `` building the corresponding `dict`. But that's the whole point of . ``/`` are supposed to supply/apply the object's dictionary, and only when something special needs to be done, without `` ever being called. If `` does need to be invoked, then we should be using ``.
Q: Can reforming this be done in a backwards-compatible way?