[petsc-dev] How to enforce private data/methods in PETSc?

[Matthew Knepley]

On Fri, Aug 10, 2018 at 11:29 PM Junchao Zhang <jczhang at mcs.anl.gov> wrote:

> It seems we do not have naming conventions for private members.
>

I am not sure I understand. There are no public members. For private
functions, we do have
a naming convention, but it is newly created, so many of the existing
functions break the rules.

   Matt


> --Junchao Zhang
>
>
> On Fri, Aug 10, 2018 at 9:43 PM Matthew Knepley <knepley at gmail.com> wrote:
>
>> On Fri, Aug 10, 2018 at 5:43 PM Junchao Zhang <jczhang at mcs.anl.gov>
>> wrote:
>>
>>>  I met several bugs that remind me to raise this question. In PETSc,
>>> object of type A can arbitrarily access object of type B's data. But
>>> designer of B may later change the meaning of its data (and of course,
>>> update B's interfaces, which are usually local to few files). The designer
>>> may think the job is done, but actually it is not.  He/she has to grep the
>>> code to know where its data members are accessed (that is relatively easy
>>> to get) and what is the contract, for example, is an array assumed to be
>>> sorted (that is hard to know).  With C++, one can use private to minimize
>>> data exposure.
>>>
>>
>> This just has to be coding discipline. People should not be accessing
>> private members.
>>
>>    Matt
>>
>>
>>> --Junchao Zhang
>>>
>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>>
>

-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180810/66bbaa28/attachment.html>