From 4377454331378473437
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,388934337992c65c
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-04-05 08:10:12 PST
Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.std.c++
Subject: Re: Overloading and 0
Keywords: overloading, NULL, ambiguity
Message-ID: <1992Apr5.151012.9269@jyu.fi>
Date: 5 Apr 92 15:10:12 GMT
References: <1992Apr2.153121.4155@wam.umd.edu> <rmartin.702315640@willing>
Organization: University of Jyvaskyla, Finland
Lines: 40

In article <rmartin.702315640@willing> rmartin@willing.Rational.COM (Bob Martin) writes:
>krc@wam.umd.edu (Kevin R. Coombes) writes:

[A lot deleted]

>>After all, there is only one accessible constructor; why not just use it?
>
>IMHO this would not be a good strategy.  The accessibility of a
>function is meant to prevent its use out of context, not as a
>specifier of which function to use.  It would be very very odd if A
>a(0) had two different meanings depending upon the function it was
>used in.  Moreover, if the accessibility of a function changed over
>the course of time, code which used to work could break.  e.g. by
>moving the declaration of a member function from private to public
>access, you could change the way the program works (break it.).

That's the common argument for why the principle of controlling
_access_ and not _visibility_ was chosen in C++.  Nevertheless,
in my opinion the disadvantages of this decision are greater
than the advantages.  Moving a member from private to public status
or vice versa is a change of the _interface_ of the class:
a thing that should usually be avoided and is always apt to break clients.
On the contrary, adding a new private member is something that should
_not_ disrupt anybody except the class itself and its friends;
but in C++ it does.
See my paper, "A critique of the inheritance principles of C++",
to appear in Vol. 5 No. 1 of Computing Systems, whenever it comes out.

----------------------------------------------------------------------
Don't smell rotten -- avoid a "look and smell" litigation from
Apple Computer.

Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------