bill@robots.oxford.ac.uk (Bill Triggs) (06/15/91)
I have recently been pushing the suggestion that 'soft' or calculated class members would be easy to implement in C++, and would be a useful extension of the language. 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, 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. 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. I would like to get the ANSI C++ committee to at least consider the introduction of soft members into C++, as I think they would be a great benefit to the language. I posted a detailed proposal on the net a few weeks ago and the response was favourable, so I have now posted some patches which implement soft-members for g++ - look in the gnu.g++.help newsgroup if you want more details... -- Bill Triggs Oxford University Computing Laboratory 11 Keble Rd Oxford OX1 3QD
miller@FS1.cam.nist.gov (Bruce R. Miller) (06/15/91)
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!...)
sdm@cs.brown.edu (Scott Meyers) (06/15/91)
Regarding whether to allow data member notation for function members: In article <2885931374@ARTEMIS.cam.nist.gov> miller@FS1.cam.nist.gov (Bruce R. Miller) writes: | Why not just make all of them get parenthesis! (whoops, lisp showing | through again!...) This is actually less whimsical that you suggest. I always encourage people to make *all* their public members functions, because then for users of the public interface, things are much simpler -- no need to guess whether to use data member syntax (no parens) or function member syntax. Most everyone overlooks the fact that a class's public interface is a kind of user interface: the users are application developers. They gain from conceptual consistency, too. Of course, there are times when data members in the public interface make perfect sense, but substantially less frequently than most people seem to believe. Scott ------------------------------------------------------------------------------- What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."