Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | If you desperately need to protect against abuse of your classes, you need
| > | "private". On the other hand, the most likely "abuser" are yourself, so
| > | you pay (writing accessor functions, compile times, probably run time) for
| > | something you might not _really_ need.
| >
| > with accessors you can eaily change from a cached value to a generated
| > one... this is impossible if you alway access the variable directly.
|
| I think I know the pro's and con's. I was just stating my opinion (short of
| other thing to work on right now. *sigh*)
|
| How often do you use that functionality compared to the occasion where you
| don't need them? 1 out of 100?
|
| It probably depends on how one answers the following question:
|
| What is easier (only in the case where variable access is not part of the
| interface to the ouside world of course): Write no accessors in general and
| put some in only in case they are really needed or write 99% unneeded
| functions and be happy if you need one?
All variables as private, add accessors for those that really need
some visibility from outside.
| I think the both of us are answering this questions differently so we end
| up with different conclusions.
|
| > [..]
| > then I am going to claim that the responsibility for the count
| > variables is wrongly placed, and _that_ is why you end up with the
| > ugly code.
|
| Note that I was talking about protected <-> private. The class is
| manipulating part of itself. If 'count_' is not an implementation detail of
| the base class (in which case it definitely should be private), but 'part
| of the object', it should be accessible painlessly.
And that is another thing ... the "_" should only be used on private
variables not in protected or public.
Your pain is not mine it seems.
--
Lgb
