Path: utzoo!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!agate!linus!linus!mir!dsr
From: dsr@mir.mitre.org (Douglas S. Rand)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <1991Mar18.154503.16330@linus.mitre.org>
Date: 18 Mar 91 15:45:03 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <1991Mar17.184122.717@mathcs.sjsu.edu>
Sender: news@linus.mitre.org (News Service)
Reply-To: dsr@mir.mitre.org (Douglas S. Rand)
Organization: The MITRE Corporation
Lines: 48
Nntp-Posting-Host: mir.mitre.org

In article <1991Mar17.184122.717@mathcs.sjsu.edu>, horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
> In article <624@taumet.com> steve@taumet.com (Stephen Clamage) writes:
> >
> >In particular, you would not define both operator dot and operator arrow
> >for the same class.  The result would be unmanageable.  
> 
> I don't think that is true at all. First of all, inside a MEMBER FUNCTION
> of X (a class with both operators . and -> overloaded), you could still access
> the members. That should be sufficient for implementing such very specialized
> classes. Furthermore, if X::operator& is not redefined, member access is
> still possible through (&x)->m, since -> cannot be overloaded for the pointer
> type X*. 
> 
> I am NOT saying that operator. should necessarily be overloadable just because
> it can be done. Just that the most common argument ("it would be a mess to
> access members") doesn't hold water. Just out of curiosity: has the working
> group identified any code that would break if operator. overloading was 
> permitted? (Stephen cited that as one important task of the working group.)
> 
> The most important question is of course: Does it solve any problems? Recently
> it was generally agreed that it would be useful for defining an access class
> which can be both an lvalue and an rvalue. Is anyone aware of another use for
> it?
> 
> Cay

Yes,  it would allow the creating of true persistent objects where there was
little, if any, programmer overhead of dealing with them.

To explain;  the persistent object implementations I've done all require me to
explicitly force the loading of an object either at construction time or before
the first access.  Lazy loading of objects is then very difficult and for a large
system one definitely wants to load objects on a "as needed" basis.

When a programmer modifies an object one needs to update a writeback list or directly
store the instance.

With overloaded "." one can check for the load state of the persistent instance on
access and automatically load the instance.  This is much cleaner.  With overloaded
"." as an lvalue one can increment writeback lists automatically or store through to
the database.

-- 
Douglas S. Rand 
Internet:   <dsrand@mitre.org>
Snail:	    MITRE, Burlington Road, Bedford, MA 
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ