Why go outside the java type system.

• To: "William L. Hibbard" <WHIBBARD@xxxxxxxxxxxxx>
• Subject: Why go outside the java type system.
• From: "Glenn P. Davis" <davis@xxxxxxxxxxxxxxxxxxxxxxx>
• Date: Tue, 3 Mar 1998 17:21:50 -0700

Bill:

Sorry if I asked you this before, but I don't recall the answer.

In looking at VisAD, I'm struck by the extent of effort to make a
"type system" distinct from the Java language type system.

I'll try to clarify what I'm getting at.
One of the main things we are trying to accomplish is provide a
general framework for describing "functions" or "mappings". In order
to do this, a way to describe the domain and range "sets" is needed.
A lot of the VisAD classes exist to do this, at various levels of
specificity.

It seems to me that the java language type system could be used instead.
When one specifies a "function", one would specify the Class of the domain
and the Class of the range. In the case of a sampled function, the methods
for adding samples to the function would verify the type of domain and range
using the instanceof operator or java.lang.Class.isAssignableFrom().

Consider the parallel relationship between java.lang.Class.getFields()
and java.visad.getDimension() (returns number of "fields"),
java.visad.getComponent() to return the "field" by index.

The problems with the approach I'm considering include
        class Class is final
                - but probably has everything we really need.
        class Class has no public constructor
                - use ClassLoader as factory

It seems like the custom ClassLoader might be used to simplify some other
aspects of the system as well. We talked a bit about how Data seems to reinvent
the interpreter for math operations. The classes that pop out of the
ClassLoader
could have the proper methods defined properly.

I realize that this short message isn't very clear or specific enough.
I guess what I'm seeing is that you got started on VisAD before reflection
hit the streets.

regards

-glenn