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@gmail.com>