This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]