Subject: [Fwd: Operator Overloading in Java (how it may be realize)]

From: Ronald F Boisvert <[email-masked]>
Date: Thu, 25 Feb 1999 09:45:57 -0500

-------- Original Message --------
Subject: Operator Overloading in Java (how it may be realize)
Date: Wed, 24 Feb 1999 18:32:17 +0400
From: prognoz <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]

The purpose: rise of visualization of calculating programs on Java at
the expense of the extension of possibilities of the compiler:
   - reformation of operators for objects into calls of methods of a
class or instance;
   - reformation of pseudo-functions into calls of methods of a class or
instance.

At development of calculating programs on Java (in particular by
operation with complex numbers) visualization of the source code
strongly suffers. It complicates process of designing and supporting of
programs.

The essential difference of the source code from the habitual
mathematical language is caused by absence in Java of functions and
possibility of an operator overloading for objects.

The methods realizing functions and operators for objects can is both in
classes of objects, and in other classes. So some assume, that whenever
possible it is better to take out any operations for objects in the
separate class (similarly to a java. lang Math).

Operator overloading and the pseudo-functions can be realized by
creation of the "templates" object, which not realize the execution of
the operators or functions, but "knows" a realizing method (of a class
or instance) and format of call to it. In this case:
   - there is no necessity for duplicate of the source code;
   - there are no additional limitations on names of methods realizing
the operators or the functions;
   - there are no additional limitations on a location of a realizing
method, methods can be as:
      - a method of an instance using in the operator or the
pseudo-function;
      - a method of the class, which instance using in the operator or
pseudo-functions;
      - a method of any other class.

The "informator" ("templates", "macro") object should support:
  - addition of the description of the operator or pseudo-function;
  - to have the necessary interface for usage of the descriptions.

The "informator" object can be realized by different ways, for example
by such: the description of pseudo-function contains:
  - name of function (for example "sin");
  - list of types of parameters (for example "java.lang.Double");
  - pattern of a reformatted string (for example
"Math.sin(%1.doubleValue())");
the description of operator can be similar to the description of
pseudo-function, where instead of a name of function the operator symbol
is used, for example :
  - "+";
  - "java.lang.Double ", " java.lang.Double ";
  - "new java.lang.Double( %1.doubleValue() + %2.doubleValue() )";

The type of returned value can be determined or using Reflection API, or
setting one more string (though last is worse).

Using "informator" object it is possible "to realize" pseudo-functions
and operator overloading at compilation. For this purpose it is
necessary to inform the compiler required "informator" objects (for
example similarly to operator "import" or in another way) and to add
preprocessing of strings containing initialization of objects or
expression (including for parameters of methods and pseudo-functions).
In this case overloading of operators and the pseudo-functions only are
emulated (since the form of recording varies only), not conflicting with
Java ideology. Thus the user himself determines what "informator"
objects are necessary for the package (i.e. what operators or the
pseudo-functions are supposed to be used).

Basically it is possible to realize dynamic execution of the overloading
of operators and  pseudo-functions. For this purpose it is necessary to
realize object, which on the basis of "informator" object (or list of
"informators") perform operators and pseudo-functions.

For an example we shall consider some descriptions of pseudo-functions
from objects abc.Complex and description of operators between objects
abc.Complex and primitive types. The class abc.ComplexFunction contains
methods for operators and functions for objects abc.Complex.

Example of the description:

<Name> < types of parameters >        <pattern>
"+"    "abc.Complex", "abc.Complex"   "abc.ComplexFunction.add(%1, %2)"
"+"    "double", "abc.Complex"        "abc.ComplexFunction.add(%1, %2)"
"+"    "abc.Complex", "double"        "abc.ComplexFunction.add(%2, %1)"
"+"    "int", "abc.Complex"          
"abc.ComplexFunction.add((double)%1, %2)"
"sin"  "lib.Complex"                  "abc.ComplexFunction.sin(%1)"
"cos"  "lib.Complex"                  "%1.cos()"
"-"    "abc.Complex", "abc.Complex"   "%1.min(%2)"
"="    "lib.Complex","double"         "new Complex(%1, 0.)"
"="    "lib.Complex","int"            "new Complex((double)%1, 0.)"

The initialization of object is submitted as operator "=", since
externally it looks as equal operator in a line of the object
definition. The initialization and automatic transformation of types -
not same is necessary to note. In C++ the automatic transformation of
types is realized through initialization. In Java there is no automatic
transformation of types.

Description of the abc.Complex class:

   package  abc;
   public class Complex {
      public Complex(double re, double im) { ... }
             ...
      public Complex cos() { ... }
      public Complex min(Complex c) { ... }
             ...
   }

Description of the abc.ComplexFunction class:

   package  abc;
   import  abc.Complex;
   public class ComplexFunction {
      public static Complex add(Complex c1, Complex c2) { ... }
      public static Complex add(double d1, Complex c2) { ... }
             ...
      public static Complex sin(Complex c) { ... }
             ...
   }

In result we shall receive the following transformation to methods of
classes and instance:
  Complex a=1;                       Complex a=new Complex((double)1,
0.);
  Complex b=2.;                      Complex b=new Complex(2., 0.);
  Complex c=a+b;                     Complex
c=abc.ComplexFunction.add(a, b);
  Complex d=a-b;                     Complex d=a.min(b);
  a=3;                               a=new Complex((double)3, 0.);
  b=cos( sin(a) );                   b=abc.ComplexFunction.sin(a).cos();

The offered expansion of the compiler Java has the following advantages:
   - does not change the ideology of Java;
   - creates illusion of overloading of operators and presence of
functions, that allows to write more evident programs (since a source
code as much as possible comes nearer to habitual mathematical
language);
   - allows to describe operators and pseudo-functions for existing
classes without their correction.

The offered decision can be realized as preprocessor, but in this case:
   - it is necessary practically to write one more Java compiler;
   - the time of compilation is essentially increased;
   - it is impossible to use IDE.

Similar preprocessor can be built - in the developer environment (IDE),
that will make this IDE popular among the developers.

If you will like this idea, help it to be realized. 

Thanks.