[93] in java-interest
String handling solved
daemon@ATHENA.MIT.EDU (todd@mars.clarit.com)
Thu May 18 13:57:56 1995
Date: Thu, 18 May 1995 13:44:54 -0400
From: todd@mars.clarit.com
To: java-interest@java.Eng.Sun.COM
I found some interesting discussion in the archive about the
string-concatenation issue. Hope I'm not bringing up old news,
but it still warrents some investigation.
Arthur van Hoff (avh@eng.sun.com)
Wed, 19 Apr 1995 12:18:33 -0700
|
| Jeremy Fitzhardinge (jeremy@sour.sw.oz.au)
| Wed, 19 Apr 1995 16:14:03 +1000 (EST)
| > It seems that the toString mechanism is a hack to get around not
| > having multiple inheritance: the effect is to make any class
| > treatable as a String type, which is the same effect as if you had
| > String as a super class.
|
| Yes it is a hack. But it is + that is a hack, not toString().
| It would have been possible to get rid of + for string concatenation
| and require you to call toString() explictly. That would be
| very verbose but it would work fine.
I disagree. As I said in my previous message, the issues of operator
overloading and auto-conversion are semantically orthogonal.
Let's suppose we first use :: as the string concatenation operator,
so we completely resolve the operator-overloading issue.
With just that change, we could replace Scott Hudson's example
int i = 1; int j = 0; System.out.println("Test: " + i+j);
with the clearer code
int i = 1; int j = 0; System.out.println("Test: " :: i+j);
This would work as expected, but as Scott (I think) mentioned you probably
want to give :: a very low precedence.
| > [Thinking aloud...] Could it be replaced with a Stringable interface
| > which objects could implement? It would be a pain if the interface
| > had concat, etc which needed to be implemented by everything wanting
| > a string representation when all they really need is a toString
| > implemnetation. To fix that you'd need to have implementations in
| > interfaces, which just makes them like classes, and you suddenly
| > have MI and all its advantages and disadvantages.
|
| Right. So lets not do that.
Actually, I think Jeremy is on the right track.
I use a similar design in C++: a Printable superclass to supply
the PrintOn() method, overloaded << on Printable, and thats it.
So how would this really look in Java? How about something like:
public interface Stringable
{
String toString();
}
public class String
implements Stringable
{
String toString() { return this; }
// ...
}
There is no need to include concatenation, for the only thing we are
abstracting over is the ability to self-convert to a string.
Then the signature of the concatenation operator is simply:
Stringable :: Stringable --> String
This design avoids multiple-inheritance and its associated problems.
More importantly, however, it keeps the entire mechanism
INSIDE THE LANGUAGE, and doesn't resort to special hacks.
.T. ...Suggestively...
. . . Todd V. Jonker . . . . . Systems Designer . . .
. . . todd@clarit.com . . . . . CLARITECH Corp. . . .
http://www.contrib.andrew.cmu.edu/usr/tj00/home.html
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
