sieve-dev [Roy Stogner] Re: [Libmesh-devel] LibMesh namespace?

[Jed Brown]

On Mon, 21 Jun 2010 20:25:07 +0000, Matthew Knepley <knepley at gmail.com> wrote:
> On Mon, Jun 21, 2010 at 5:18 PM, Jed Brown <jed at 59a2.org> wrote:
> 
> > Heads up about this namespace collision, seems less appropriate for
> > PETSc to claim Mesh:: than for libMesh.
> 
> 
> Crap, its the C side. I hate that anyway. I am cool with changing 'Mesh'
> to 'PetscMesh' since all these C symbols should be properly namespaced
> like my C++.

Certainly nobody would want to use "ALE::" for say, an Arbitrary
Lagrange Eulerian code, or have a header named Field.hh, Generator.hh,
Mesh.hh, Numbering.hh, etc [1].

> The only reason that 'Vec' and 'Mat' are not is history and
> convenience. However, I do not buy the appropriateness argument at
> all.

One could certainly argue that libMesh is a bad (not sufficiently
distinguished) name, but it does produce libmesh.so (not liblibmesh.so)
which makes "Mesh" a reasonably appropriate namespace (not as good as
"libMesh" only because "Mesh" is so common).  A PETSc component named
Sieve claiming the namespace "Mesh" is far more of a stretch.

Jed

[1] I suggest #include <sieve/Mesh.hh> if you don't want these header
names to include the PETSc name somehow, now you require that they
-I$PETSC_DIR/include/sieve which makes those header names completely
public.

On this note, I don't like "private/vecimpl.h", it is much more common
(look at your /usr/include) and collision-free to do "petsc/vecimpl.h"
or even "petsc-private/vecimpl.h".

Jed