Re: operator overloading
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---910079544-837489031-1211904890=:20026
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Tue, 27 May 2008, Patricia Shanahan wrote:
Tom Anderson wrote:
On Mon, 26 May 2008, Patricia Shanahan wrote:
Wojtek wrote:
Arne VajhHj wrote :
Operators only make the code more readable for classic arithmetic.
Which is my point.
Maybe this subthread suggests a solution. Define, for example, an
interface Addable<T> with
T additionOperation(T o);
as its only method.
Analogising to multiplication, this is going to make it impossible to write
my Matrix class which can be multiplied any of a double, a Vector, or
another Matrix, because you can't implement multiple instances of a generic
interface. Well, you could, but you'd have to do an instanceof switch
inside additionOperation, or implement some kind of ugly bounce dispatch.
Anyway, i'm not happy with this solution, although i appreciate and
strongly agree with its intent.
Good point. How about this modification?
Addable, Multipliable, etc. become marker interfaces. Suppose a is a
reference to Multipliable or a type implementing Multipliable. Then the
compiler would process a+b as though it were
a.multiplicationOperation(b).
I'm happy with this. What you describe is exactly how it works in python
or C++, with a slightly different method name, and requiring a marker
interface. Could we even drop the marker interface? What do we gain by
having it?
If you're talking about handling this as a rewrite rule, then the type of
the receiver variable would have to have a suitable multiplication method.
You couldn't multiply a plain Multipliable, but overloading would work.
That's fine by me.
The alternative to doing it by rewriting would be to do a fully dynamic
invocation, but that's clearly madness, and doesn't preserve type safety,
eg:
Multipliable m = new Matrix(23, 17) ;
Object result = m * new GaloisField(7).getElement(5) ; // O NOES!
tom
--
Any problem in computer science can be solved with another layer of
indirection. -- David Wheeler
---910079544-837489031-1211904890=:20026--