> From: Barry Smith > > On Aug 17, 2011, at 2:50 PM, Chetan Jhurani wrote: > > > I never meant to say that one must put const ints in the > > declaration. > > Our problem is that because one compiler warns if the const is not listed > in both prototype and > definition we must put it in both (to avoid tons of warning messages that > people installing PETSc > should not see) we MUST put them in the declaration. Which we wanted to avoid > since it is anti- > encapsulation. So for now, they are forbidden in all PETSc code even though > yes they can be useful in > implementations.
I understand. One has to take care of many platforms and compilers that all behave differently. Anyway, after this discussion I could realize why I have no problem with code that has const ints in declaration and definition and why it doesn't break encapsulation (for me). The philosophy is that -- and I'm not telling this to convert anyone to my philosophy or to use my definition of encapsulation :-) -- just exposing inner details is not an encapsulation problem. Rather, if the exposure allows the interface user to rely on it and suffer compatibility problems if the inner details change, only then is it an encapsulation problem (for me). In the ongoing example, the user sees const int and can assume that function will not change the int. If this behavior changes, say using a const_cast, or not having the const int in function definition, then it cannot affect the caller. Inner details are exposed, but the caller cannot use the extra details to have any choice in a decision! So nothing will break due to this exposure and no new dependency is created due to it. "There is only one thing a philosopher can be relied upon to do, and that is to contradict other philosophers." -- William James ;) Chetan
