Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!nntp.coast.net!howland.reston.ans.net!torn!nott!cunews!dbuck
From: dbuck@superior.carleton.ca (Dave Buck)
Subject: Re: The Future of Smalltalk Performance?
X-Nntp-Posting-Host: superior.carleton.ca
Message-ID: <DLHMF9.Cvn@cunews.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <4crvvl$jd5@news.jf.intel.com> <4die9l$2tk@rex.sfe.com.au> <DLD2yo.850@cunews.carleton.ca> <4dougr$rgv@citadel.evolving.com>
Date: Sat, 20 Jan 1996 16:13:57 GMT
Lines: 61

In article <4dougr$rgv@citadel.evolving.com>,
Todd Blanchard <tblancha@evolving.com> wrote:
>Dave Buck (dbuck@superior.carleton.ca) wrote:
>: Case 2:
>: Most C++ programmers (I think) follow the golden rule that if
>: a member function doesn't change any instance variables, then
>: it should be declared as const.  This technique, however,
>: breaks encapsulation by providing to the outside world
>: some details about the implementation of the method.  
>
>This shows a complete lack of understanding of what const methods are for.
>Declaring a method const is a promise to the caller that calling the
>method will not alter the state of the object in any visible way.

A member function declared as const promises not to change the state
of the object.  This has an impact on how much the caller of this
function has to cleanup (hence, there's a speed improvement) and the
C++ world claims that it better documents the design intent of the
member function.

I argue that const breaks encapsulation by leaking out details about
the implementation of a member function - details which the callers
have no right knowing.  I hardly think that this constitutes "a
complete lack of understanding of what const methods are for".

>: And, since const member functions can
>: only call other const member functions, changing one function
>: from const to non-const may require changing the callers to
>: be non-const as well and so on and so on.
>
>Again, incorrect.  Changing a function from const to non-const has no effect
>anywhere on already written code.  It is a loosening of a restriction.
>Changing a method from non-const to const tightens the restriction about 
>who can call the method.  This may required some recoding, but it is 
>possible to supply const and non-const versions of the same method 
>with different implementations (and semantics).

I think you have it backwards.  Consider:

class A {
    public:
       const int x();
    };

class B {
    public:
       A a;
       const int y() {return a.x() + 5};
    };

Changing A's member function x() to remove the const means that B's
member function y no longer compiles.

David Buck
dbuck@ccs.carleton.ca

_________________________________
| David K. Buck                 |
| dbuck@ccs.carleton.ca         |
| The Object People             |
|_______________________________|
