> | 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?
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.
But that's religion...
Andre'
--
André Pönitz ............................................. [EMAIL PROTECTED]
