Re: Restricting access should be illegal?
In article news:<44c9dc11$1@news.kapsch.co.at>, Gerhard Menzl wrote:
I don't care what the compiled code looks like, I am talking about
source code cruft, ...
This is getting a bit silly, I'm afraid, but I don't see lines mentioned
anywhere in there.
Sorry. I know we're arguing over a small point, but I'm keen to discover
whether I'm missing something I ought to understand, or just failing to
make myself understood (I'm beginning to think it's a bit of both). Thanks
for your persistence ...
In an earlier post you wrote:
Who said anything about lines? I said it's three times as much code.
and my I took that to mean that if you weren't talking about lines (i.e
*source* code) you must be talking about something else -- *binary* code.
I understand now that that's not what you meant. My fault.
So you get two function declarations and one function invocation for one
function declaration. Every parameter appears three times instead of
once. That's a factor of 3 : 1. I don't care what the respective numbers
of lines are, it's three times as much code that has to be maintained.
I see how you're counting that now. I don't see that as a big price to pay
for the the advantages I see in the longer form ... but I do now understand
why you say "three times as much".
I concede that if you take derived classes into account, the overall
ratio will be lower ...
Indeed.
It is in the nature of idioms that they have to be thought about *less*,
and that they are *less* likely to engender bugs, providing they are
applied correctly, of course.
It's the nature of idioms that they are idiomatic. They are a useful aid to
communication among those who understand the idiom, while actually
hindering communication with those who don't. This is an area of C++ in
which I understand the communication but am surprised by the idiom.
Any programmer vaguely familiar with object-oriented design and design
patterns will recognize this instantly.
Not really ... I'm more than vaguely failiar with OO design and with
patterns, and experienced enough at C++ to recognize what the code is
doing, but I don't consider it a clear and intuitive use of the language.
I'd rather spell things out and minimize surprises than use language
'tricks'.
Then again, you haven't worked with some of the other programmers that I
have ...
I don't see what "a single point of entry for debugging" buys you.
[snip]
It's defensive programming on my part. I always try to write code in a way
that will be easy to debug should the need arise. Fortunately the need
usually does not arise, but I still find it a useful exercise.
If you need to log in the base class, then, of course, it ceases to be a
mere abstract interface, and hiding the virtual function behind a public
non-virtual function is justified, just as it is with precondition
checks.
I do tend to write preconditions wherever I can, and I suspect I structure
the code in the same way even when there is no test I can reasonably make.
Call that my idiom, if you will.
class NetworkObserver
{
public:
virtual void HandleNetworkEvent(NetworkEvent* event) = 0;
};
[snip]
If you keep the original access level, HandleNetworkEvent() becomes
part of the public interface of Communicator. Every client may call
it. But of course that is not what you want.
[snip]
Thanks for the example. Yes, I see what you mean ... I don't remember
offhand exactly how I've done this in the past, I'll have to think about
it.
I don't think the orthogonality of access level and overriding belongs
in this category. Access level governs who is allowed to call a function
or access a variable. It does not affect overriding. While it may
surprise people, it's conceptually clean and consistent. That many C++
programmers are not familiar enough with the language to be aware of
this does not qualify it as a dirty quirk.
Logically (though not in C++) I feel that the access level of (in your
example above) HandleNetworkEvent is part of the definition of the
interface. If another class publishes that interface (derives from it
publicly) then I consider the publicness of HandleNetworkEvent to be a part
of that interface, and to have to be preserved. Some languages require
this, though C++ doesn't. When I think about the programming problem at an
abstract level (and maybe have to map that thought onto a real programming
language later) I find myself thinking about the interface as a whole, and
seems illogical to break that whole. This sort of conceptual consistency
seems more natural than what C++ provides.
You are right, though, that it is C++'s job to enable, not to prevent, so I
suppose there is no harm in it ... I just find it "feels wrong".
--
Daniel James | djng
Sonadata Limited | at sonadata
UK | dot co dot uk
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]