On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith <[email protected]> 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