On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith <bsmith@xxxxxxxxxxx>
wrote:
2) properly name-space PETSc by putting a Petsc in front of all
PETSc
objects, function names etc
(this will require changing a few names also to keep them below
the 32 character limit). This will
be very painful change for some users who are not comfortable
ever changing code, hence I hesitate
to do it, but it is the right thing to do and should have been
done originally.
I guess I still do not see the need for this. NIMROD is a not a
sufficient
driver in my mind.
You are an elitist who thinks that important ideas can only come
from important/smart people. This I disagree strongly with, one
should
look everywhere, even at the local dump, for good ideas. NIMROD is
not the driver, it is merely the spark.
I will be more specific. I think there is no good idea connected
with this
requirement of NIMROD. In fact, I think it is a very very bad idea.
They are
using a language with namespaces (F90) but they ignore them. Then they
wonder why uses a product from a language without namespaces (C) they
have a problem. The wrong strategy is to do something complicated in
the
deficient language. The right thing to do is something easy in the
language
with support.
Why can't we just do an F90 binding with namespaces? That would fix
NIMROD
and not disrupt the community who has not complained (and who is much
much bigger).
If we really want namespaces, use a real language that
has namespaces. There are plenty. If we are still using C, I say we
stick
with the old division. The imposition of this much pain on the
overwhelming
majority of users seems unjustified.
You seem to be saying we should stick with a bad decision I made
many years ago, just because it is painful to change. When did you
suddenly become conservative?
No, I am saying that the fix is crap because it is complicated,
entails
enormous changes to the code, and is ugly. I think the correct fix is
to use nice mechanisms in languages that support them, like C++.
I am completely against forcing weak language mechanisms to do
complicated things, which is why I hate all those template tricks.
Also, we should look at history. We have made mistakes in the past
when changing the interface (KSPSolve() with no arguments) which
were painful. I want to make sure what we choose to do is as simple
and non-painful as possible.
Matt
--
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