This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Java array class is not kawa Class?
The problem is that core Java "reflection" is poorly designed.
When I need to work with an object that represents a Java class,
it can come from (at least) 3 different sources:
(1) A compiler needs to deal with a class as seen in the source
code. For example, when Kawa sees a define-simple-class it
creates a data structure representing the various Scheme
properties (a ClassExp), which it thens translates into a
lower-level data structure representing fields and methods
(a ClassType).
(2) A class file contains another representation of a class.
(3) The JVM creates a java.lang.Class object, which is used
by both the JVM and reflection.
The life-cycle is from (1) to (2) to (3). The gnu.bytecode
API is designed to be useful for all 3 purposes: You can
create a gnu.bytecode.ClassType using reflection (i.e. from
a java.lang.Class); from reading a .class file; or the
compiler can construct one as needed from source code.
So when you ask "how do you get ArrayType from array",
I could answer your question:
Type.make(array.getClass())
But the real question is: Why do you want it? What
are you planning on doing with the ArrayType?
> I see that some methods return 'true' and some '#t'. I know that
> must have something to do with which type is actually returned by the
> methods, although I'm not sure why two Kawa methods ('eq?' and
> 'instance?') should have different results.
Actually, it's bug in output formatting (printing). If you do:
(define r (....))
and then print r, you'll find that #t/#f is printed.
Re-doing output formatting to avoid this anomaly is on the
list of things to fix before the 1.10 release.
--
--Per Bothner
per@bothner.com http://per.bothner.com/