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

[Andy Ray Terrel]

On Mon, Jun 21, 2010 at 4:09 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Mon, Jun 21, 2010 at 9:02 PM, Jed Brown <jed at 59a2.org> wrote:
>>
>> 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].
>
> You can say that about any name.
>
>>
>> > 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.
>
> We both do mesh stuff. I do not see why it is "more legitimate" for them to
> do it.
> The idea is to make it easy to coexist.

I am told that it will be changed in the libMesh library as well.  Not
the next release which is going to be soon, but the one after that.

>
>>
>> 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.
>
> I thought this was changed for PETSc 3. Now it should be sieve/Mesh.hh. I
> agree
> the other way is wrong.
>
>>
>> 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".
>
> I am cool with petsc-private.
>    Matt
>
>>
>> Jed
>
> --
> What most experimenters take for granted before they begin their experiments
> is infinitely more interesting than any results to which their experiments
> lead.
> -- Norbert Wiener
>