🚀 go-pugleaf

Joe Buck (jbuck@Synopsys.COM) wrote:
: Dan Holmsand <dan@et.se> writes:
: >Is operator.() banned from the standards discussion?

: Yes, I suppose it is, but since you brought it up I'll discuss it anyway.

[text elided]

: I think that this rejection was a mistake, as the lack of operator dot
: complicates the implementation of delegation (e.g. in classes that use a
: reference-counted representation object where the representation object
: has virtual functions).  I subscribe to the "write things once"
: philosophy, and hate long lists like

I'm afraid there is something I don't understand about this approach.  For
a nontrivial class, one in which you have a delegate pointer and other
members, how would you propose the compiler discriminate between
overloaded (delegative) member selection and the selection of actual
members of the class?  This would become an issue as soon as a member
function tries to access member data or a user of the class attempts to
form a call to a member function.

Only one scheme is immediately apparent to me; use a two-step member
selection candidate approach.  Whether actual or delegative members are
given precedence in such a scheme, the approach would be incongruent and
perhaps contradictory with how the language solves other problems.

The -> operator has the advantage that it signals the delegation property
of the member selection when it's performed.  It's easy enough for the
programmer to ignore that aspect when it's adventageous for him to do so. 
It is also easy enough to identify that aspect when it is an issue.  "I
know this identifier is a reference or an object but here is this pointer
member selection operator being used so I know delegation is being used."
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]