Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!osu-cis!att-cb!clyde!watmath!watdragon!violet!gjditchfield
From: gjditchfield@violet.waterloo.edu (Glen Ditchfield)
Newsgroups: comp.lang.c++
Subject: Re: Why doesn't c++ allow overloading member operators?
Message-ID: <5868@watdragon.waterloo.edu>
Date: 21 Mar 88 16:41:44 GMT
References: <11778@sri-spam.istc.sri.com> <8180005@eecs.nwu.edu>
Sender: daemon@watdragon.waterloo.edu
Reply-To: gjditchfield@violet.waterloo.edu (Glen Ditchfield)
Organization: U. of Waterloo, Ontario
Lines: 38

In article <8180005@eecs.nwu.edu> morrison@eecs.nwu.edu (Vance Morrison) writes:
>
>    The question is "why doen't c++ allow you to overload the "." operator.
>
>    I asked myself this very question and I don't have a good reason, but
>I did realise that the "." operator is fundamentally different from most
>other operators.  Namely its right operand MUST BE A COMPILE TIME CONSTANT
>DEFINED FOR THAT PARTICULAR CLASS/STRUCTURE.

You are treating "." as an infix operator whose right operand must come
from some nameless, magical enumerated type.  I think that the original
writer meant that ".fieldName" would be treated as a postfix operator:
"struct s { int a;};" might create a function named "s::operator .a".
The field reference "anS.a" would be equivalent to "operator .a(anS)".

Next problem: what is the returned type?  "int& s::operator .a()" seems
likely, since field a is normally an lvalue.  But a is not an lvalue if the
structure it is contained in is not an lvalue.  Perhaps two friends are needed:
"int& operator .a(s& someS)" and "int operator .a( (const s)& someS)".

(Digression:  I wish C++'s type system had a good way to express the
concept of "lvalue".  Reference types don't quite do it.  I'd love to see
discussion of the subtleties of this, under another subject heading.)

Another problem is that "." functions are often proposed as a way of
getting lvalue pseudo-members.  A Trellis/Owl paper (in OOPSLA '86?)
gives as an example a thermostat object whose setting is changed by
assigning to the "Celsius" field or to the "Fahrenheit" field.  The value
assigned is treated as a temperature from the appropriate scale.  One (or
both) is a pseudo-member that scales the given temperature and sets other
members.  This won't work in C++, because assignment is an operator that is
evaluated after its left operand.  I haven't decided whether lvalue
pseudo-members are good things or not.  We can argue about that, too.

Glen Ditchfield                              watmath!violet!gjditchfield
Dept of Computer Science, U of Waterloo         (519) 885-1211 x6658
Waterloo, Ontario, Canada			   Office: MC 2006
If you grab the bull by the horns, you at least confuse him -- R.A.Heinlein