home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!mole-end!mat
- From: mat@uunet.uu.net!mole-end
- Subject: A message forwarded to Jim Adcock
- Message-ID: <1992Jul23.174142.29983@uunet.uu.net!mole-end>
- Organization: :
- Date: Thu, 23 Jul 1992 17:41:42 GMT
- Lines: 171
-
- >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
-