[1799] in java-interest
more on class String
daemon@ATHENA.MIT.EDU (Graham Matthews)
Sun Sep 17 01:11:09 1995
Date: Thu, 14 Sep 1995 10:23:40 +1000
From: Graham Matthews <graham@pell.anu.edu.au>
To: java-interest@java.sun.com
The standard reply to my query about how to add some functionality to
class String is to define my own class MyString along the following
lines,
>The most `easily' and probabily not the best way to solve your situtation,
>create MyString subclassed from Object. Then provide as methods a String
>contructor and a toString function. Put some kind of representation of a
>String in your class. Now comes to tricky part, do your function need
>access to the internal representations of String ( for the most part you
>can probably get away with using the provided implementation of String). If
>so then implement all of the normal String methods on your new data
>representation as well as your new functions. Otherwise implement the
>String methods in your class as pass throughs to you r internal String.
>Example:
>
>class MyString { // subclass from Object
> String myString;
>
> MyString() { ... };
> MyString(String str) { ,,, };
>
> charAt(int index) { // this is a string method.
> if (myString != null) {
> return myString.charAt(index);
> }
> return -1;
> }
While this is a solution (and perhaps the only solution), it is truly an
awful solution. If I want MyStrings to have the same functionality as Strings
(which I do since they are Strings!) I have to write a wrapper method in class
MyString for every single method in class String. ie. for each method in class
String, I have to have a method in class MyString of the form,
class MyString
{
/* instance variable */
String the_real_string;
my_method(MyString s) { return M(the_real_string) }
....
}
where M is the appropriate method on class String. Apart from the fact that
having to do all that coding is a real pain in the neck, what happens when
a new version of class String is brought out with some new functions. I
then have to update MyString with some new wrapper definitions! BLECH!
Someone else commented,
> How about a StringParser class? You would probably associate a given String
>with each StringParser; StringParser's constructor would take a String.
>
> I see very little need to treat Strings and StringParsers polymorphically.
The discussion above should be ample evidence for why I want to treat Strings
and StringParsers (ie. MyStrings) polymorphically. As a simple example I
want to write a routine which takes a string of the form "/a/b/c/d" and splits
it up into a list of the form ["a", "b", "c", "d"]. I also want to be
able to treat the original string as just a String (since I want to index
it, extract substrings, etc, etc). Another example, I have a string of the
form "$A/fdf/$B/dfdfd" and I want to write a routine which takes such a
string, and a list of substitutions for the $X arguments, and returns a new
string with the substitutions applied. However once again I want to be able
to treat such strings as normal strings to do all the other string operations.
It seems to me that the kind of thing I want to do here (namely adding a
collection of routines to an existing class *WITHOUT* changing its
represenation), must be a very common thing to want to do. I can see myself
wanting to add lots of routines to compute things about integers for
example.
graham
A cat named Easter
He say "will you ever learn"
Its just an empty cage girl
If you kill the bird
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
