Name: rm29839 Date: 11/25/97
Inheritance is no longer the biggest buzz-word in OOP, but it is still a useful behaviour. In some cases it would be nice
to be able to attach additional attributes to a String by making it and
ExtendedString.
I fully realize that the Class String is fundamental
to the operation of the Java language and that the behaviour of the String methods should not be possible to
change by an overload. However
the protection of the String objects behaviour can just as well be accomplished by making all
of the methods final.
My actual problem is that the Borland J-Builder
environment make use of instances of String
returned in response to a selection in some of
the GUI components. It is frequently desirable
to be able to associate the returned string with
a some extra attributes. The same string may
appear more than once in the GUI, so a lookup
using a Hashtable is not the solution.
The actual solution is that Borland should used
a new class instead of java.lang.String. Let's
call it BorlandString, which has one field, which is a java.lang.String. This class can then be extended by the user if
he/she wants to add
user-data to the string object references returned at selection.
The problem that I have with the Borland IDE
classes can off course be worked-around, but
I still suggest that the class java.lang.String is
made non final and that all of its methods are made final.
This will allow inheritance without jeopardizing
the behaviour of the class.
The problem that I have will reoccur in other
situations and with other products and if it is
not harmful to the development of the Java
language I would very much like to see this change.
Background:
I am not playing with Java. The problem occured while writing a major business critical application created in Java for a
customer. This application will get a lot of publicity when it is launched. It is a part of a new wireless communication system
at the edge of
technology. First customer deliveries will be in '98.
The "write-once, run anywhere" is important to this application in the longer run, since it may well end up running under
other operating systems than Windows-NT. Typically, a Unix
environment is next in turn for a test.
BTW: I was pleased to see that Sun has filed
a lawsuit towards MS. Keep up the good work
to protect Java from the evil empire!
Regards
Joakim Langlet
(Review ID: 20795)
======================================================================
Inheritance is no longer the biggest buzz-word in OOP, but it is still a useful behaviour. In some cases it would be nice
to be able to attach additional attributes to a String by making it and
ExtendedString.
I fully realize that the Class String is fundamental
to the operation of the Java language and that the behaviour of the String methods should not be possible to
change by an overload. However
the protection of the String objects behaviour can just as well be accomplished by making all
of the methods final.
My actual problem is that the Borland J-Builder
environment make use of instances of String
returned in response to a selection in some of
the GUI components. It is frequently desirable
to be able to associate the returned string with
a some extra attributes. The same string may
appear more than once in the GUI, so a lookup
using a Hashtable is not the solution.
The actual solution is that Borland should used
a new class instead of java.lang.String. Let's
call it BorlandString, which has one field, which is a java.lang.String. This class can then be extended by the user if
he/she wants to add
user-data to the string object references returned at selection.
The problem that I have with the Borland IDE
classes can off course be worked-around, but
I still suggest that the class java.lang.String is
made non final and that all of its methods are made final.
This will allow inheritance without jeopardizing
the behaviour of the class.
The problem that I have will reoccur in other
situations and with other products and if it is
not harmful to the development of the Java
language I would very much like to see this change.
Background:
I am not playing with Java. The problem occured while writing a major business critical application created in Java for a
customer. This application will get a lot of publicity when it is launched. It is a part of a new wireless communication system
at the edge of
technology. First customer deliveries will be in '98.
The "write-once, run anywhere" is important to this application in the longer run, since it may well end up running under
other operating systems than Windows-NT. Typically, a Unix
environment is next in turn for a test.
BTW: I was pleased to see that Sun has filed
a lawsuit towards MS. Keep up the good work
to protect Java from the evil empire!
Regards
Joakim Langlet
(Review ID: 20795)
======================================================================
- duplicates
-
JDK-4218669 Library classes (String, etc.)declared final, instead of methods declared final.
-
- Closed
-