changes for next PETSc release

[Lisandro Dalcin]

Well, Fortran 90 modules provide a sort of namespace support, I think.

On 3/17/08, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>     Fortran90 has namespaces??????
>
>
>  On Mar 17, 2008, at 12:59 PM, Matthew Knepley wrote:
>
>  > On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith <bsmith at mcs.anl.gov>
>  > 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
>  >
>
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594