[1883] in java-interest
re: extending String functionality
daemon@ATHENA.MIT.EDU (John D. Mitchell)
Tue Sep 19 09:53:08 1995
Date: Tue, 19 Sep 1995 04:31:37 -0700
From: "John D. Mitchell" <johnm@mitchell.org>
To: Glen.Perkins@MediaCity.com (Glen C. Perkins)
cc: java-interest@java.sun.com
In-Reply-To: <v01510100ac834fc3a732@[192.0.2.1]>
Glen C. Perkins writes:
> I must have been asleep, but I didn't realize until this thread started
> that most of the fundamental classes (String, Integer, Float, etc.) are
> "final" classes meaning they can't have subclasses.
Yep, it is certainly a painful decision from the OO/reusability/etc. point
of view.
They did it for security reasons. To a first or even second approximation
the performance hacks could always be done by having the writers of those
final base classes collude with the compiler (writer). Smalltalk
implementations do that sort of thing to make things (a lot) faster.
[...]
> If those classes are all dead ends, sorry, "final", was the intention that
> we create a new base class ("MyString" was mentioned, but I'll call it
> "SuperString") that simply encapsulates a String attribute, then subclass
> it to create JIS1String, ThaiString, etc?
>
> Do we then create an array of SuperString instead of String if we want to
> work with an array containing different types of strings?
But you would still *not* be able to using SuperString and String
interchangably because they don't match up anywhere (class-/type-wise).
Even doing something like making an Interface wouldn't work because String
still wouldn't be 'implement'ing it (which is the whole point of security
:-).
[...]
> Another poster was mentioning having to create wrappers for all of the
> methods in String in order to include them in this homemade base I'm
> calling "SuperString". If I were to do it, I'd just call the methods of the
> String variable encapsulated within the subclass. For example, I create the
> class "SuperString" and it has one variable in its definition:
[...]
> That way, I don't have to build wrappers for all of the String methods so
> that my non-final SuperString class would be able to use them.
Either way you pay a price. I'm of the school of thought that you should
do the extra work to write the wrappers to do the delagation (to the String
in this case) because though it's a pain up-front it's a one shot deal
whereas changing all of the accessors to use the extra indirection (through
either a get() style method or through the (public) instance variable
directly) is an ongoing extra cost and hassle.
Take care,
John
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
