PRE-PROPOSAL: Simple operator overloading. (original) (raw)

Vilya Harvey vilya.harvey at gmail.com
Thu Mar 26 04:33:12 PDT 2009

D'oh! Of course you're right.

I'm probably flogging a dead horse now, but perhaps widening conversions could be dealt with by implementing the interface in a common superclass? For example in the case of BigDecimal and BigInteger, Number would implement the Addable interface and it's implementation would be responsible for doing any widening and returning the result in the appropriate subclass.

On second thoughts, that seems like a poor solution. Anything which requires superclasses to have knowledge of their subclasses is a Bad Thing. You wouldn't be able to add a class of your own which existing numeric types could widen to, for example. Imagine adding a class for complex numbers; to support widening you'd have to make it a subclass of Number and modify the implementation of Number's add method.

This leads back to either not having implicit widening for overloaded operators, or using a non-interface-based approach like Ruslan's annotation proposal.

Hmm.

2009/3/26 Daniel Cheng <j16sdiz at gmail.com>:

On Thu, Mar 26, 2009 at 5:00 PM, Vilya Harvey <vilya.harvey at gmail.com> wrote:

You're right, I hadn't considered widening conversions. You really want multiple dispatch in order to solve this elegantly, but somehow I don't see that being added to java anytime soon. :-) So I guess that leaves two options (for the interface-based approach): you could throw ClassCastException, forcing the user to do the conversion themselves; or you could do something like this with generics:

interface Addable<R, T> {  R add(T val); } class BigInteger implements  Addable<BigInteger, BigInteger>,  Addable<BigDecimal, BigDecimal> { ... } class BigDecimal implements  Addable<BigDecimal, BigInteger>,  Addable<BigDecimal, BigDecimal> { ... } Interface with generic is the same interface.  -- and you can't implement same interface twice. I don't want to talk about generic Type Erasure, it's a PITA. I admit that doesn't look too elegant anymore, but I think it addresses the issue. Do you see any other problems there that I've overlooked? Cheers, Vil. Sent from my iPod [...]

More information about the coin-dev mailing list