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


On Friday 04 March 2005 13:36, Per Bothner wrote:
> The base class isn't "immutable".  Rather, it lacks methods for
> mutation.

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 inheritance relationship between Timestamp and
  | java.util.Date really denotes implementation inheritance, and not
  | type inheritance.

In practical terms, this casuistry has predictably led to bugs:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16574


> (1)
> abstract class string
> class mutable_string extends string
> final class immutable_string extends string
...
> (2)
> class string
> class mutable_string extends string
...
> (3)
> class string
> final class immutable_string extends string
...
> A problem with (1) is how do you prevent people from deriving a new
> class from string?

Why is this problem particular to (1)?  What would stop people from
subclassing the base class in (2) or (3)?

As for the practical aspects of preventing unwanted subclassing of a
non-final class, one possible is answer is this.  You can't stop
people from deriving a new class, but what you can do is make it
maximally unpleasant.  Declare all (or most) public methods of the
base class final.  Document the fact that the class is not supposed to
be subclassed by anyone other than the implementor.

> 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.
Whether this distinction is going to be easily understood and
remembered by most users is open to debate.



Footnotes

  1. http://people.csail.mit.edu/people/gregs/ll1-discuss-archive-html/msg04644.html
  2. http://java.sun.com/docs/books/jls/first_edition/html/4.doc.html#24887
  3. http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#24887


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