This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: kawa-java string compatibility proposal
Vadim Nasardinov wrote:
Hair splitting strikes me as a dangerous design choice. This reminds
me of the following gem in J2SE:
http://java.sun.com/j2se/1.3/docs/api/java/sql/Timestamp.html
| Due to the differences between the Timestamp class and the
| java.util.Date class mentioned above, it is recommended that code
| not view Timestamp values generically as an instance of
| java.util.Date.
The SQL API is design disaster, period. The way PreparedStatement
inherits from Statement is just totally wrong.
(It might have been better to use Calendar rather than Date, though
the fact that both java.sql and Calendar were introduced in JDK 1.1
may have led to coordination problems.)
The inheritance relationship between Timestamp and
| java.util.Date really denotes implementation inheritance, and not
| type inheritance.
In other words: use type inheritance, not implementation inheritance,
when designing an API.
In practical terms, this casuistry has predictably led to bugs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16574
I think you have it backwards. It's the *lack* of casuistry (i.e. not
following accepted object-oriented design rules) that led to the bug.
Why is this problem particular to (1)? What would stop people from
subclassing the base class in (2) or (3)?
Nothing. However, in those cases the types/function (mutable-string? x)
and (immutable-string? x) are still likely to "work". If I subclass
the abstract string, is the new class mutable or immutable?
Note that in (2) "new string(...)" does create an immutable value,
but string is not an immutable class.
Casuistry. If all instances of class Foo (i.e. values created by
"new Foo(...)") are immutable, then Foo is immutable.
> Now, you can say -- as Steele did in [1,2,3] -- that "values have
> classes, variables have types". In this terminology, the "string"
> _type_ is mutable, although the string _class_ most certainly isn't.
Right: The *type* Foo is not "all instanceof class Foo". It is "all
instances of class Foo or Foo's subclasses or null".
> Whether this distinction is going to be easily understood and
> remembered by most users is open to debate.
Well, does it matter if they don't? The class Fstring is the type
of string; mutable or immutable; mutable string have class VString.
That's not terribly hard.
It might be an idea to make FString constructors private, and just
have factory methods:
class FString {
private FString(...) { ...}
public static FString makeConstant(String s) { ... }
public static FString makeConstant(char[] c, int offset, int length) { ...}
public static VString makeMutable(String s) { ... }
public static VString makeMutablee(char[] c, int offset, int length) { ...}
}
--
--Per Bothner
per@bothner.com http://per.bothner.com/