class and type values

[Per Bothner <per at bothner dot com>]

I'm working on a few changes to type and class values.
Comments welcome.

First, my impression is that some Kawa programmers are
confused by the distinction between standard java.lang.Class
objects, and the more general gnu.bytecode.ClassType objects.
A ClassType is often just a simple wrapper around a j.l.Class value,
but it can also include a lexical context for a nested class,
including a class that references module-level non-static variables.
A ClassType can also be a "pair" of a Java class and an interface,
as created by define-class, to support multiple inheritance.

Currently, an expression like <java.util.Vector> evaluates
to a ClassType, not a j.l.Class.  Similarly, a
  (define-simple-class <Foo> (...) ...)
declared <Foo> as a constant whose value is a ClassType
not a Class.

This may be surprising to people; at least that is my impression.

So one idea is to change Kawa so that the result of evaluating
  <java.util.Vector>
is a java.lang.Class value, rather than a gnu.bytecode.ClassType value.
Similarly, the name declared by a define-simple-class would be a
j.l.Class value, not a ClassType value.

The name declared by a (non-simple) define-class would remain a
ClassType, since it actually is more complex than a plain Class.

Kawa would also automatically coerce between Class and ClassType.
If the ClassType is non-simple, coercing to Class raises a
ClassCastException.  Coercing from (non-array non-primitive) Class
to ClassType always succeeds.

A corollary is that if you write a nested class you'd use
define-class rather than define-simple-class, so we can have
the simple rule that a define-simple-class declares a Class name,
while define-class declares a ClassType name.  Some existing code
would violate this, but it should be possible for Kawa to make
this a warning rather than an error.

Finally, I want to move away from the angle-bracket <CLASSNAME>
convention.  I think it looks ugly in conjunction with colon
notation, as well as direction constructor invocation.  Instead of:
  (<java.lang.Math>:sin 2.0)          ; static method
  (<java.lang,StringBuffer> "value")  ; create new
I think these could look less cluttered:
  (java.lang.Math:sin 2.0)            ; already supported
  (java.lang,StringBuffer "value")

So we'd end up with:
  java.lang,StringBuffer
would evaluate to java.lang,StringBuffer.class.   However,
this would only be the same if the identifier (in this case
java.lang,StringBuffer) does not have a compile-time (lexical)
binding *and* the identifier is the name of an a class that
exists at compile-time in the context class-path.

Comments on this idea?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/