Name: skT45625			Date: 06/08/2000


java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)

Quite often I find that the best, most efficient way to code certain types of
methods is to code them using variable length argument lists.  This
functionallity would be nice to have in Java.  It is occassionally adequate to
use method overloading to get the same functionality as variable length argument
lists, but many times the types and number of the parameters to be passed are
not known at the time the code is written.  Code is also much easier to maintain
if all of it is in one method instead of spread throughout dozens of overloaded
methods.  Believing that method overloading can always supply the same
functionallity as variable length arguments is quite naive I have found.

The classic example of the necessity for variable length arguments is the printf
function in C.  Neither the number nor the types of the arguments are known in
advance.  I have found many other times when this is the case.

Unlike C, Java has a built-in mechanism which would be quite adequate to support
this feature.  All that would be needed is the addition of one keyword (or use
of a currently unused reserve word) and support in the compiler. The keyword
would be needed to denote the point in the argument list where the variable
aspect takes affect.  The compiler would then know to take all the remaining
arguments and "wrap" them in an Object array.  The user could also specify a
name after this "variable length keyword" which would be the name of the
Object[] that is created.  In this way, no extra keyword would be needed for the
name of this array.  There would also need to be _no_ change to the class file
format to support this, as it would simply look like another parameter passed to
the method.  If no "optional" parameters are passed, the compiler would simply
create a zero length array.

So an sprintf like function in Java may look like the following:

public String sprintf(String format, VARLIST params);

The method would then parse the format string to find the type of the parameters
and proceed from there.  Of course, all native types would need to be wrapped in
one of the java.lang classes.

The user could then check the length of the array to find out the number of
extra parameters, and could use some mechanism built-in to the other parameters,
or the Java instanceof keyword to look for expected types.

Such functionality would greatly enhance the ability to write and maintain
efficient code.
(Review ID: 105913) 
======================================================================