On Fri, Aug 10, 2018 at 11:29 PM Junchao Zhang <jczh...@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 <knep...@gmail.com> wrote: > >> On Fri, Aug 10, 2018 at 5:43 PM Junchao Zhang <jczh...@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/>
