On 23 March 2011 20:09, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Mar 23, 2011, at 5:58 PM, Lisandro Dalcin wrote: > >> Are you going to rename MatNullSpaceDestroy -> MatNullSpaceDestroy_ >> and add the backward compatibility #define? Changeset 1a6f5fc1c27b >> broke petsc4py... > > ? No, it was changed to the &object paradigm. > > ? Basically what is happening now is that commonly used destroys are changed > with the _ paradigm > > ? Uncommonly used destroy are fixed to use the &object paradigm. >
Understood... I'm going to fix petsc4py... > > ? Don't like the fact that there are two paradigms well I could change > everything to & immediately :-( > :-) > > ? Barry > > ? Eventually I want to switch to the &object paradigm for everything but I > decided to be nice to Matt and leave the common ones with the same API so > users don't have to change their codes much. > I still feel we should use a different approach for backward compatibility... Perhaps adding a petsccompat.h header file (or even compat/petscXXX.h headers) with backward compatibility macro defs and even STATIC_INLINE routines, in order to help people switch incrementally. My concern is that if you do not make pressure on users RIGHT NOW to forcibly notice there is a new API's, most of them are going simply ignore the changes, pretend they old API is fine to use, and finally cry in the next release petsc-3.3 because their code is finally broken. Please note that this is the approach I use for petsc4py, right now petsc4py-dev can build back to petsc-3.0.0. Of course, a potential petsccompat.h should have a reverse direction of compatibility for what I have in petsc4py -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
