Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <1991Mar21.032937.16534@world.std.com>
Date: 21 Mar 91 03:29:37 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <12193@pasteur.Berkeley.EDU>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 69

jbuck@galileo.berkeley.edu (Joe Buck) writes:
> |> Q3. What functionality will be added to the language which is not now
> |>     conveniently available?  (What problem does this solve?)
>
> The new functionality is the ability to have "smart references".  The
> semantics parallels the semantics for "smart pointers" obtained by overloading
> operator -> and should have the same restrictions.

That doesn't answer the question -- all you've done is to give the new
feature a name.  The real issue is whether the technique solves any major
problems that can only be addressed awkwardly or not at all in the existing
language.  In other words, give some specific applications that demonstrate
that "smart references" aren't just another of the hundreds of nifty ideas
floating around that are cute and interesting but don't really expand the
power of the language to address real-world problems.

To give an example, exception handling was added to the language because
there simply is no way without it safely to employ a non-local goto to
terminate a failing operation.  As a negative example, generalized
overriding (aka "renaming") was a very attractive feature that was rejected
in large measure because a fairly straightforward programming technique was
discovered that solved the problem to which the extension was originally
addressed.

For instance, one proposed use of operator.() given in this newsgroup a
short while ago was to implement auxiliary classes used as the return type
of operator[]().  It's not apparent to me, at least, that defining
operator.() in such a class is sufficiently superior to the alternate
technique of coding any necessary forwarding functions directly into the
auxiliary class.  In fact, addressing the original problem (detecting the
difference between lvalue and rvalue use of the result of operator[]()) will
require coding some glue functions into the intermediate class to allow the
desired separation between lvalue and rvalue operations, so the relative
value of operator.() for such an application is reduced even further.

> |> Q4. Do the benefits in Q3 make up for the costs in Q1 and Q2?
>
> Since there are no costs in Q1 and Q2, obviously.  Of course, there is
> a cost for compiler writers, and a cost for the standards committee.

Actually, those aren't the only costs; some of the conceptual unity of the
language will be lost if operator.() is adopted.  For one thing, it is
currently absolutely guaranteed that, if you see "foo.bar" in a program,
"bar" is a member of the class of which "foo" is an object.  That guarantee
will be broken if operator.() is adopted; you'll have to look at the
definition of the class of "foo" in order to know what the expression means.

Perhaps more important is the fact that a fundamental identity in the
language will be broken.  In at least the form of the proposal I have seen
(although there are others, I believe), "p->m" and "(*p).m" are no longer
equivalent by definition if "p" is a pointer to a class in which operator.()
is defined.  This is the only case in which a fundamental C identity is
broken for a non-class type (a pointer to a class object is a built-in type,
not a user-defined type).

These are non-trivial costs, at least to me, even if they can't be evaluated
in terms of number of lines of code requiring modification.  Don't get me
wrong, here; I'm not fundamentally or irrevocably opposed to the idea of
operator.(), I just want to be sure that there are good, solid reasons for
adopting it beyond "it sure is a nifty idea."

> Smart references will make it easier to write garbage collectors (though
> the C-compatible array semantics can leave holes in the scheme).

This sounds promising, like what I was asking for above.  What do smart
references buy that smart pointers don't with respect to garbage collection?

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com