Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Henderson <h1@g1.f1>
Newsgroups: comp.lang.java.programmer
Subject: Re: Arithmetic overflow checking
Date: Sat, 23 Jul 2011 22:55:00 -0400
Organization: e1
Lines: 45
Message-ID: <j0g1i4$nus$1@speranza.aioe.org>
References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <l_qdnfmZ-4tpt4vTnZ2dnUVZ_sqdnZ2d@earthlink.com> <koic171t5gas91890r8l9914v26snm7k1v@4ax.com> <b3d4a08b-3428-442a-8cce-30edc2868a47@5g2000yqb.googlegroups.com> <09fe171s46ilvq9qmn254dctunm6noh0ps@4ax.com> <f6ed8d08-bc7a-43e4-aecf-878511705353@j15g2000yqf.googlegroups.com> <4e262731$0$314$14726298@news.sunsite.dk> <j059o8$684$1@dont-email.me> <4e26300b$0$309$14726298@news.sunsite.dk> <cdyVp.5929$Vn5.2217@newsfe18.iad> <4e26b4ed$0$2501$db0fefd9@news.zen.co.uk> <f126e0ad-e1e5-47c8-949e-e38b3598d5ff@m5g2000prh.googlegroups.com> <4e28097f$0$2533$da0feed9@news.zen.co.uk> <f9939820-502d-4973-b008-0b62536ab967@m3g2000pre.googlegroups.com> <slrnj2ghv0.6gl.avl@gamma.logic.tuwien.ac.at> <7a23c9d2-508f-4dbd-af91-8cdf2a9764e1@p29g2000pre.googlegroups.com> <j09t06$4bo$1@dont-email.me> <slrnj2jc3u.6gl.avl@gamma.logic.tuwien.ac.at> <IMBWp.68441$5v5.52239@newsfe11.iad> <slrnj2mdoi.6gl.avl@gamma.logic.tuwien.ac.at>
NNTP-Posting-Host: cJ+uP0NdDAbt8UCZbZVtiQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: WinVN 0.99.12z (x86 32bit)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6495

On 23/07/2011 5:03 PM, Andreas Leitgeb wrote:
> It is my opinion, that operator overloading at least for a certain
> limited set of JSL classes (including BigDecimal and BigInteger as
> well as some new Complex class in addition to String's +), would
> be beneficial.  Ditto for a new "strictint" keyword to enable
> detection and handling of integer overflows.

An obvious suggestion would be to allow it on all java.lang.Number 
subclasses, but a + b among these is only defined if a is a Number class 
that has an overload of .plus(x) that is applicable to an argument of a 
supertype of b, and the most specific such is chosen; and if a is a 
primitive, is treated as b + a; a * b analogously; a - b with a 
primitive uses (b - a).negate() and expects the return type of minus to 
support negate(); and for division we likewise need .reciprocal().

We could go further and rewrite Number.java so that it is Number<T 
extends Number<T>> and defines:

public T plus (? super T)
public T plus (int)
public T plus (long)
public T plus (float)
public T plus (double)
public T minus (? super T)
public T minus (int)
...
public T times (? super T)
...
public T dividedBy (? super T)
...
public T negate ()
public T reciprocal ()

or something of the sort. I think short overloads can be left out as 
they can just auto-promote to int and use the int version and the int 
version won't be less efficient, unlike (on 32 bit hardware) the long 
version.

The operator expressions then become shorthands for the method calls 
above, and generate compile time type errors if one is needed and 
missing, e.g. MyBigInteger.plus(BigInteger) is not defined but 
MyBigInteger.plus(MyBigInteger) is and one mixes the two types in a + 
expression. (Integer etc. needn't be explicitly supported as 
autounboxing can be used to call the primitive plus (int) or whatever if 
necessary.)