On Wed, Mar 23, 2011 at 7:12 PM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 23 March 2011 20:09, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Mar 23, 2011, at 5:58 PM, Lisandro Dalcin wrote:<br>
><br>
>> Are you going to rename MatNullSpaceDestroy -> MatNullSpaceDestroy_<br>
>> and add the backward compatibility #define? Changeset 1a6f5fc1c27b<br>
>> broke petsc4py...<br>
><br>
>   No, it was changed to the &object paradigm.<br>
><br>
>   Basically what is happening now is that commonly used destroys are changed with the _ paradigm<br>
><br>
>   Uncommonly used destroy are fixed to use the &object paradigm.<br>
><br>
<br>
Understood... I'm going to fix petsc4py...<br></blockquote><div><br></div><div>I already fixed MatNullSpaceDestroy().</div><div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

><br>
>   Don't like the fact that there are two paradigms well I could change everything to & immediately :-(<br>
><br>
<br>
:-)<br>
<br>
><br>
>   Barry<br>
><br>
>   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.<br>
><br>
<br>
I still feel we should use a different approach for backward<br>
compatibility... Perhaps adding a petsccompat.h header file (or even<br>
compat/petscXXX.h headers) with backward compatibility macro defs and<br>
even STATIC_INLINE routines, in order to help people switch<br>
incrementally.<br>
<br>
My concern is that if you do not make pressure on users RIGHT NOW to<br>
forcibly notice there is a new API's, most of them are going simply<br>
ignore the changes, pretend they old API is fine to use, and finally<br>
cry in the next release petsc-3.3 because their code is finally<br>
broken.<br>
<br>
Please note that this is the approach I use for petsc4py, right now<br>
petsc4py-dev can build back to petsc-3.0.0. Of course, a potential<br>
petsccompat.h should have a reverse direction of compatibility for<br>
what I have in petsc4py<br>
<br>
<br>
<br>
<br>
--<br>
<font color="#888888">Lisandro Dalcin<br>
---------------<br>
CIMEC (INTEC/CONICET-UNL)<br>
Predio CONICET-Santa Fe<br>
Colectora RN 168 Km 472, Paraje El Pozo<br>
3000 Santa Fe, Argentina<br>
Tel: <a href="tel:%2B54-342-4511594">+54-342-4511594</a> (ext 1011)<br>
Tel/Fax: <a href="tel:%2B54-342-4511169">+54-342-4511169</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>