Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!cam!ARTEMIS
From: miller@FS1.cam.nist.gov (Bruce R. Miller)
Newsgroups: comp.lang.c++
Subject: Re: 'soft' or calculated class members
Message-ID: <2885931374@ARTEMIS.cam.nist.gov>
Date: 14 Jun 91 23:36:14 GMT
References: <1875@culhua.prg.ox.ac.uk>
Sender: news@cam.nist.gov
Followup-To: comp.lang.c++
Organization: NIST - Computing and Applied Mathematics Laboratory
Lines: 46


In article <1875@culhua.prg.ox.ac.uk>, Bill Triggs writes: 
> ..
> The basic idea is that while it is good OOP style to 'wrap'
> class member access with method calls (for reasons given
> below), the resulting code is made difficult to understand
> by the resulting brackets, ...

Is `brackets' UK talk for US parenthesis?  I dont find that they make
code hard to understand (but then I like lisp, so...)

>				and the valuable conceptual
> difference between "little operations which just access
> state" and "big operations which actually do something" is
> blurred when everything is done with an explicit function
> call.

Is this a valuable conceptual difference?  It seems to me, only for the
implementor of that class.  As I see it, _hiding_ that distinction is one
of the strengths of OOP.  The classic example would be:

  complex.realpart();
  complex.imagpart();
  complex.magnitude();
  complex.phase();

Which is accessing state and which is doing something?
It doesn't matter!  (other than, after establishing usage patterns in a 
given application, one might choose one implementation over another --
but _purely_ for efficiency (well, round off error too...) 

> Soft members are class *methods* which can be invoked by a
> syntax identical to ordinary *member* accesses (ie,
> 'foo.bar' not 'foo.bar()'). They can be used to simulate
> non-existent 'notional' class members, for various extremely
> useful housekeeping tasks, and for easier maintenance of
> backward compatibility.

Which sounds to me like you are proposing to further hide the
distinction!  ie.  seeing foo.bar we know it is accessing state, with
foo.bar() we dont know.  Now you say with foo.bar we wont know either.
So far, that's fine with me, but you are providing _yet
another_ choice for us c++neophites to wonder about! :>

Why not just make all of them get parenthesis! (whoops, lisp showing
through again!...)