This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
converting to String in Kawa
- From: Per Bothner <per at bothner dot com>
- To: kawa at sources dot redhat dot com
- Date: Wed, 21 Nov 2001 17:31:42 -0800
- Subject: converting to String in Kawa
I recently checked in a "fix" to how converting to java.lang.String is done:
The types <String> and <java.lang.String> new behave differently,
finally matching the documentation. The type <java.lang.String> now
works just like (say) <java.util.Hashtable>: Converting an object to a
<java.lang.String> is done by a single coercion, so the incoming value
must be a java.lang.String reference or null. The special type
<String> converts any object (but *not* null) to a java.string.String
by calling toString.
The biggest downside to this is that people have to be a lot more
careful when using invoke and invoke-static. For example, the
following used to work:
(invoke-static <java.lang.Class> 'forName "java.lang.Object")
However, now you have to write:
(invoke-static <java.lang.Class> 'forName 'java.lang.Object)
or if you prefer (required if you have spaces or delimiters):
(invoke-static <java.lang.Class> 'forName '|java.lang.Object|)
This breaks a lot of code, which is a bummer. Also, it was nice
that people could use double-quited strings. I'm not sure what the
solution is. It would be easy enough to change Kawa back so it does
use toString to convert to Strings - we can even do this just
changing the Scheme-specific code, wihout changing gnu.bytecode.
But it does mean you would not be able to pass #!null, and it
doesn't seem the right solution. I can put in code so that #!null is
special-cased, and non-null objects are converted using toString.
I could also put in code that adds a special check for FString
(the implementation type for Scheme strings), and otherwise
does a plain cast. Both of those solutions add extra overhead, though
it should be possible to often optimize it away.
It may also be possible to add a special case for literal strings.
This isn't just a concern for String. We get a similar issue for
java.lang.Integer vs gnu.math.IntNum for example, but since
very few methods take or return java.lang.Integer (they return
int instead) it is much less of a problem.
--Per