🚀 go-pugleaf

In article <4easfd$puc@news2.delphi.com> jodle@bix.com (jodle) writes:

> 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.

There's a long discussion of operator. in D&E, and some of it
addresses precisely this point.  If you're interested in operator.,
you may find that discussion useful: it may not change your opinion of
whether or not operator. is a good idea, but it'll probably give you a
clearer idea of some of the issues.

I've never had a strong opinion about operator. one way or the other
(I have slightly different operator fetishes), but I do think it's
quite clear that operator. will not make it into the C++ standard.
Still, it's interesting from a theoretical and historical perspective.

-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
---
[ 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. ]