[536] in java-interest
Re: Operator overloading (was: BigInteger class out there?)
daemon@ATHENA.MIT.EDU (jim frost)
Thu Jun 29 01:56:01 1995
To: Greg Wilkins <gregw@ind.tansu.com.au>
Cc: java-interest@java.sun.com
In-Reply-To: Your message of "Wed, 28 Jun 1995 17:57:20 EDT."
<199506280757.RAA09646@ostrich.cssc-syd.tansu.com.au>
Date: Wed, 28 Jun 1995 10:55:07 -0400
From: jim frost <jimf@world.std.com>
|Once you have operator overloading, your really need automatic
|conversions to make the sugar look really nice
The obvious counter to this argument is to only allow operations that
require no conversion (ie for which an explicit rule exists).
Unfortunately even that's not simple.
If you make operator overloading assymetric, eg C++:
class foo {
operator+(int);
};
then to get symmetric relationships you must be able to add operators
to existing classes at will (eg int::operator+(foo)), with all the
ugliness which that implies.
If you decide to allow symmetric rules inside classes you introduce
ambiguity, eg (using a hypothetical C++-like language):
class bar;
class foo {
public:
foo operator(foo, bar);
foo operator(bar, foo);
};
class bar {
public
foo operator(bar, foo);
foo operator(foo, bar);
};
Which do you use for foo + bar? You also introduce privacy issues, as
the operators probably need access to private members.
The obvious "solution" is to use global rules, eg C++:
class foo;
foo operator(int,foo);
foo operator(foo,int);
which also creates member privacy issues (besides violating the OO
spirit), although it's clearly the only unambiguous way to handle the
task.
Assuming that you can deal with the privacy issues coding explicit
rules is incredibly tedious. Consider the simplest case:
class foo;
foo operator(char, foo);
foo operator(foo, char);
foo operator(short, foo);
foo operator(foo, short);
foo operator(int, foo);
foo operator(foo, int);
foo operator(long, foo);
foo operator(foo, long);
foo operator(float, foo);
foo operator(foo, float);
foo operator(double, foo);
foo operator(foo, double);
foo operator(unsigned char, foo);
foo operator(foo, unsigned char);
foo operator(unsigned short, foo);
foo operator(foo, unsigned short);
foo operator(unsigned int, foo);
foo operator(foo, unsigned int);
foo operator(unsigned long, foo);
foo operator(foo, unsigned long);
...quite a lot of work just to add a new numeric type, and of course
the work gets exponentially harder as the type system expands.
As mentioned before automatic type conversion avoids this tedium,
however it opens up considerable ambiguity. A very lengthy discussion
of how C++ manages this ambiguity is in ARM 13.2 (pp 312-327).
jim frost
jimf@world.std.com
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
