Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <275@heurikon.heurikon.com>
Date: 27 Mar 91 00:06:56 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <12193@pasteur.Berkeley.EDU> <1991Mar21.032937.16534@world.std.com> <71516@microsoft.UUCP>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 51

In article <71516@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>I disagree.  On the contrary, I believe Joe Buck, myself, and others
>have repeatedly shown what the problem is.`

In following this discussion I have noticed that most of these examples
start with the statement "I want to design some set of objects to do X and
I want to do this by using langauge feature Y in this way". It do not believe
that there is any meaning in showing that given a contrived set of
circumstances the language can not meet the needs of your program. To do so
is to expect the language to be all things to all people. What is important
is whether their is a solution set for your problem, without any contrived
conditions or usages of language features, which maps cleanly to your problem.
I believe that with some effort a clean approach that does not require
modification of the language is possible for every one of the examples given
so far. That solution starts with rethinking how you want to achieve the end
result and picking an approach that is a good fit with existing language
features.

>But, when we place all the problems
>we've found into one category which we label "smart references" some
>people argue that we're just applying a name to a category we've made up.

Since "f.thing" and "(&f)->thing are equivilent in a sense smart references
already exist. If you think of "f->thing" as being equivelent to "(*f).thing"
then it becomes clear why "->" is was originaly made overloadable and "."
was not. Since overloading of "*" is allowed how do you overload the implicit
"*" in "f->thing" (i.e. (*f).thing). The method chosen was to allow
overloading of "->". Since "." has not implicit dereference overloading was
not needed.

>And then when we show specific short examples of the problem then people 
>argue that the examples we give are academic and give hack work-arounds.

I for one do not think using "(&f)->thing" is a hack workaround. It is
quite clear to me what is intended.

>Why not just make the language orthogonal and say that its up to the 
>programmer to decide when its appropriate to use pointers, and when
>its appropriate to use references?  Why in this one obscure case in the
>language try to mandate some people's preference of pointers over references?
>Why defend an exceptional case, when it can be easily removed?

One reason I have seen given (you must have missed it) is that it alters
the syntax of the language in ways that make it hard to predict the outcome.
Currently "expression.expression" is not allowed, your change would make
it allowable. If this creates side effects then its removal will be far from
easy.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com