[petsc-dev] Remove calls to XXXReset() in XXXDestroy()

Barry Smith bsmith at mcs.anl.gov
Fri May 13 08:07:20 CDT 2011


   I think because I've never done truly serious programming in Python or C++ I haven't developed this total instinctive aversion to calling methods in the destructor. So, for me, it is a completely reasonable thing to do, while for you it appears as a cardinal sin of terribleness. Hence our difficulties in communicating, you are shocked that "Barry kills babies for their meat", while Barry doesn't understand why you are so upset that "Barry has an easy source of protein."

   Barry


On May 13, 2011, at 7:50 AM, Barry Smith wrote:

> 
> On May 13, 2011, at 7:01 AM, Lisandro Dalcin wrote:
> 
>> On 13 May 2011 01:51, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>> 
>>> On May 12, 2011, at 4:48 PM, Lisandro Dalcin wrote:
>>> 
>> 
>> Barry, now I want to understand: Why did you coded XXXDestroy() to
>> call XXXReset()? Was that just to avoid code duplication? Or is it
>> there some other rationale?
> 
>   XXXReset() is a "partial" destroy. To me it makes perfect sense that the complete destroy calls the partial destroy and then frees up the rest of the stuff. It avoids code duplication or having an extra function (for example having both XXXReset() and XXXDestroy() calling XXXPartialDestroy_Private()). If we ignore your particular Python problem, what I coded was completely natural and very arguably the "right" way to code it. Having code around like
> 
> 
>     XXXPartialDestroy_Private(XXX xxx)
>       .....
>       return
> 
> 
>     XXXReset(XXX xxx)
>        call XXXPartialDestroy_Private(xxx)
>        return
> 
>     XXXDestroy(XXX xxx)
>         call XXXPartialDestroy_Private(xxx)
>         ....
>         return
> 
>     without a really good reason is just plain ugly and unnecessary. Who would ever introduce that extra function? In understand from the perspective of Python why you don't like the way I did it, but I cannot understand any other reason to dislike it. 
> 
>     Barry
> 
>     I would state that any language that makes it impossible or cumbersome to have a destructor call another method on the destructed object (you claim python and C++?) is very fragile and should be rethought.
> 
>> 
>> 
>> -- 
>> 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
> 




More information about the petsc-dev mailing list