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]

Re: kawa-java string compatibility proposal


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>)

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

>and <mutable-string> be j.l.StringBuffer?

In that case might as well make it char[] - though that doesn't
implement CharSequence.

> My understanding of R5RS 6.5.3 (string-set! examples) is that literals are
> immutable. Isn't that what we all want?


Yup.

I believe this derivation is upside down. Either mutable and immutable strings can be siblings of an immutable class (as in the j.l.CharSequence tree), or you can derive an immutable string from a mutable one

Well, a mutable string has the same properties as an immutable string *plus* some extra methods, such as setChatAt. I.e. the derivation should be the way I wrote: a mutable string derives from an immutable string.

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

But you can't derive mutable strings from immutable ones (because you can't find out whether it is immutable by it's class which is very important information

Why? And what's wrong with !(x instanceof VString) ?


and allows you to pass an immutable object to a method that requires mutability).

Are you suggesting we want this?


If a method requiers mutability, it's parameter would be VString
(a mutable string).  Thus passing in an FString would fail - as
desired.

In a method takes an FString, it means we can pass either a
mutable or an immutable string.

I think it works.

If you could, we and everyone else would have been creating subclasses of j.l.String like crazy.

j.l.String was "designed" before Collections and before CharSequence. -- --Per Bothner per@bothner.com http://per.bothner.com/


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