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
