From: mat@uunet.uu.net!mole-end
Subject: A message forwarded to Jim Adcock
Organization: :
Date: Thu, 23 Jul 1992 17:41:42 GMT

>From fmccva!bms88!stuart  Wed Jul 22 22:58:21 1992 remote from uunet

>From: uunet!fmccva!bms88.BMSI.COM!stuart (Stuart D. Gathman)

An open letter to Jim Adcock,
(This didn't get posted properly. You may wish to post if
you think it is appropriate.)

 [So be it.  I don't entirely agree with the strength of the message, but
I do agree with its sense.  I have performed some minor line-editing, but
no token-editing. --mole-end!mat]

Dear Jim,

I have been following your (operator .) debate for some time now.  I
basically agree with you.  I think that other people do also.  They
probably wish they could admit this publicly without also admitting
to abject stupidity.  Unfortunately, your postings have continued
to reinforce "linkage" between these issues :-)  Believe it or not,
others (including Stroustrup) have agreed with you on basic issues
(not, of course, with your whole proposal).  Since you don't seem to
have noticed, I will try (at the risk of my life and reputation) to 

  a) review basic agreement between all parties.
  b) attempt to explain the (non-political) reasons why other
     parties are reluctant to adopt your proposal right now.
  c) present my own proposal :-)

I can sympathize with your frustration.  I make the same mistake on
a regular basis, antagonizing my potential allies by single minded
devotion to principle.  I have learned (but still have difficulty
practicing) that relationships are in the long run more important
than technical correctness.

IMHO, everyone seems to agree that

  "operator ." would be a good thing if properly defined.

Now, if everyone agrees on this, why did certain commitee members balk
at your proposal the first time around (before you antagonized them)?  I
am reading between the lines here, but I believe that they felt that your
obvious and straightforward definition might compromise a better handling
of *implicit* calls to "operator ." in the future.  They felt that there
ought to be a better way, but didn't have time (or inclination after
being called stupid fools) to think it through.

If I may try to summarize your proposal: you suggest that operator . should
be applied only where explicitly written in a manner exactly analogous
to operator -> .  

	a) This is simple
	b) This is easy to implement (just remove the restriction as
	   you keep pointing out).  Some have already tried it with
	   good results.

However, there are many implicit calls to "operator .".  An obvious
example are operators.  Under your proposal, one simply creates forwarding
functions for the desired operators.  This is tedious, but straightforward.
Unfortunately,

	a) This is tedious.
	b) the potential operator combinations are unbounded with
	   repect to user defined types.  This makes it impossible to use
	   a template for a smart reference (for example).

I am sure that Stroustrup has thought about this more than I have.  In fact,
I was angry when you removed the 2nd and 3rd alternatives from the analysis
of your proposal -- "because they didn't correspond to my proposal".  What
conceit!  As if your proposal is the only one that matters.  Perhaps I
could have gleaned a better idea of what Stroustrup was thinking by reading
what he considered to be alternatives to your proposal.

[Let me inject an opinion, and that is that the fewer options presented
 to x3j16 in a proposal, the better, _in general_.  The more complete the
 analysis, the more you may risk violation of this rule.--mole-end!mat]

Anyway, the tedium and unboundedness of forwarding functions don't sit
right with me (or with Stroustrup either, apparently).  Perhaps there is
a better way.  Perhaps not, but wouldn't it be awful if implementing the
immediately obvious solution were to forever mar the better way when it is
discovered?  If you want the committee to adopt an "operator ." proposal,
you must 

  a) *motivate* them to think about the ideal solution until it 
     crystallizes.  Implying that anyone who doesn't embrace
     your proposal immediately is an idiot doesn't help this strategy.

	or

  b) convince them with a rigorous proof that no other solution
     exists.

You may not think that a hypothetical ideal is worth pursuing when there
are immediate benefits to be gained by removing the current ban on
"operator .".  This is a matter of priorities - i.e. opinion.  Please
repect Mr. Stroustrup's desire to create the ideal language.  After all,
his reputation is on the line, not yours.

For example, here are some of my ideas on the ideal solution.  While they
are probably full of holes, they will illustrate this point - note how my
idea would break working legal programs using your "explicit call only" rule.

  a) "operator ." works analogously to "operator ->", returning a reference
     or structure to which the "." is again applied.  However, there
     are certain implicit uses for which there is no analogy with "operator ->".

     So in addition:

  b) a user defined "operator ." applies to *all* invokations, including
     implicit invokation through operators.
     
     Except:

  c) an accessible member is invoked directly instead of "operator ."
     - even a named member with an explicit dot.  For example,
     member functions of a smart reference can refer to internal members
     in the normal manner.  A smart reference can also override
     specific members of the class "operator ." returns a reference to 
     (the forwarded class).

  This is consistent with "operator ->" since the latter is never called
  implicitly and other members are accessible in the normal manner.

  A useful smart reference class can have only one public member in addition
  to constructors and destructors - "operator .".  Additional public members
  can override particular operators or members for special circumstances
  via rule (c).

  Rule (c) allows friend classes (and derived classes) to access internal
  members of a smart reference.  Note that -> does not allow this since an
  implicit call to "operator ." is eventually involved.

  A smart reference class implementation must be careful when referring to
  members of the forwarded class through its own "operator .".  Its own
  members will override the forwarded members.

  There is one aspect of my own proposal that doesn't sit right with me.
  It makes member protection determine scope, whereas ideally, protection 
  violations should result in compile time errors, not mysteriously
  switching the reference to another class.  This can only happen, however,
  with classes that overload "operator .".

While this definition of operator . may not be ideal either, the important
thing to note is that

  a) it has properties that I consider desirable

  b) it breaks programs written according to the explicit invokation
     only definition since not all explicit '.'s result in calls
     to "operator .".

  c) it also claims exact analogy with "operator ->".

Apparently there is more than one (incompatible) way to be
"exactly analogous to ->".

Do you see why rational C++ experts are afraid to jump on your bandwagon
without careful thought?  If you want to see the ban on "operator ." removed
from C++ sooner rather than later, you must make the individuals involved "want
it so bad they can taste it", not "feel nauseated when the subject is
mentioned". 

		Sincerely,

		stuart@bmsi.com
[Forwarded by ]
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++