Re: kawa-java string compatibility proposal

[Jim White <jim at pagesmiths dot com>]

Per Bothner wrote:

> Jim White wrote:
>
> > Per Bothner wrote:
> >
> > But wouldn't the way to go be to have <string> be j.l.String
>
> I assume you mean <immutable-string> be j.l.String, where
> <string> == union(<immutable-string>, <mutable-string>)

No, I don't believe that is necessary.  j.l.String coercion will take 
care of the cases where the programmer doesn't know and doesn't care 
about the distinction between mutable and immutable.  I would have 
<abstract-string> for j.l.CharSequence.

So the concise version of my proposal is:

<string> == java.lang.String
<mutable-string> == java.lang.StringBuffer
<abstract-string> == java.lang.CharSequence
<symbol> == gnu.mapping.Symbol (extends j.l.CharSequence)

string? == instanceof j.l.String or instanceof j.l.StringBuffer

Coerce via toString for j.l.String parameters if not instanceof 
j.l.String and instanceof j.l.CharSequence.

Near as I can tell from R5RS and SRFI-13 pretty much all the string 
functions that return a "new" copy need to return a j.l.StringBuffer.  I 
think they should take j.l.CharSequence as parameters to avoid creating 
extra copies (it would be up to the function to decide whether it is an 
error if (string?) is false - I pretty much don't think they would care 
to).  The shared versions could return j.l.CharSequence of course.

By having Symbol extend j.l.CharSequence and with the toString coercion, 
I think this will also be compatible with most current code that expects 
 symbols to be j.l.String.

> Obvious we can't use j.l.String for <string>, since String is final.

But <string> doesn't have to be extended.

> ... 
> You can think of an immutable string as a string with soem extra
> estrictions, but isn't as clean a design, I think.

I think of an immutable string as one that has the same interface as a 
mutable string but if you try to mutate it you get a runtime exception. 
 If the string is the immutable class then you already know it won't 
like you calling those methods.  If a method takes the immutable class 
(actually an interface) as a parameter it is saying it won't change the 
string (immutable-string-implementation extends mutable-string 
implements immutable-string).  But this is moot as I prefer the 
Java-based scheme above for Kawa.

Jim