home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c++
- Path: sparky!uunet!mole-end!mat
- From: mat@mole-end
- Subject: Re: Alternatives to operator.()
- Message-ID: <1992Jul21.094710.20173@mole-end>
- Summary: May I suggest ...
- Organization: :
- References: <BrGIF7.IvE@world.std.com> <1992Jul17.213335.19671@microsoft.com> <1992Jul20.235728.29058@microsoft.com>
- Date: Tue, 21 Jul 1992 09:47:10 GMT
- Lines: 30
-
- In article <1992Jul20.235728.29058@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
-
- > In case you've forgotten, I've answered these "objections" repeatedly.
-
- > | 2) Your operator.() proposal continues to require forwarding functions
- > | for member operators and conversion operators in the target class,
- > | even though the requirement of forwarding functions was one of the
- > | most significant criticisms you advanced against the status quo.
-
- > My operator.() proposal DOES NOT require forwarding functions unless
- > the implementor of the reference class DESIRES to use forwarding functions.
- > The functions that the implementor of the reference class might *desire*
- > to implement are those small set of functions that ARM currently requires
- > the LHS to be a member, . . .
-
- > | 3) Your operator.() proposal requires use of circumlocutions to access
- > | members of the smart reference object.
- >
- > My proposal DOES NOT require use of circumlocutions to access members of
- > the smart reference object. Circumlocations are POSSIBLE, if the implementor
- > of the reference class so desires. . . .
-
- Perhaps concrete examples might make these points clearer? I know they
- take more time than stating the points, and often take up many lines, but
- they have a marvellous way of clearing things up.
- --
- (This man's opinions are his own.)
- From mole-end Mark Terribile
-
- uunet!mole-end!mat, Somewhere in Matawan, NJ
-