[boost] Getters vs. constant members

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2007-03-25 14:34:55

Hello,

[ I'm not sure this really belongs to this list (as opposed to some C+ 
+ generic list), but as it is related to some comments I received a  
while ago from this list, I'm posting it here. ]

Back when I presented Boost.Process 0.1 past year, I used getters for  
all class members that had to be exposed to the library user.

However, some reviewers commented that it was "ugly" to provide  
getters that just returned a member's value.  I tried to change most  
of those instances to constant members that could be queried  
directly, but I still have doubts whether that was the correct way to  
go.

Here are my reasons supporting getters:

- The getter method can do some sanity checks before returning a value.
   Sometimes these checks can be avoided by redesigning the class to  
make
   the value directly "query-able", but sometimes not.

- It is sometimes hard, if not impossible, to implement a constant  
member.
   I don't remember the exact situation I hit, but when trying to do the
   conversion, I could not copy-construct some class because its members
   were constant.

- As sometimes getters cannot be avoided, using them in all scenarios  
makes
   the interface more consistent.

- I've always been taught that exposing a class' internals is BAD-BAD- 
BAD! ;-)

- And my preferred item: If the class' internals ever change, one can  
adapt
   the getters' code to return the appropriate values.  Which means  
the API
   is not broken.

However, constant members may be preferred because:

- The getter is overall suppressed, thus removing a level of  
indirection.

- Err, what else?

Most of the work of converting getters to constant members was  
already done in the Subversion repository, but there still are some  
methods that were not converted.  Before switching these, I'd like to  
reach a conclusion whether this is the way to go or not.

Thank you.

PS: Yes, I'm trying to continue the work on my SoC 2006 library.  I  
won't have too much time in the short term for this task, but  
resolving some of the serious issues as soon as possible could  
benefit all people interested in it.

-- 
Julio M. Merino Vidal <jmmv84_at_[hidden]>