String and StringBuilder sealed ... another WHY

[beutler]

Recently, I tried to extent class string (it could have much more
features), and ups - "cannot derive from sealed class string", so I
looked around in some groups, and, yes, I found every time the comment
that classes string and even sytem.text.stringbuilders ARE sealed.
While I can understand this for class string (it is a non-modificable,
immutuable string), I was very suprised as I see this for class
stringbuilder.

Of couse, performance optimization is one thing, but how the hell I
could extent string funcionality of .NET ? Write a wrapper class and
forward all methods or what ? That would have to do nothing with
object-orientation, and, when learning a new language, I would not
make two steps backward in design questions...

Sorry, but this is my first contact with C# (I'm coming from C++), and
I'm already shocked. I'm excited what other surprises C# would bring
for me

So please tell me, are there any further reasons why they don't allow
to inherit from both classes, are there any other similar classes or
proposals to extent string functionality in an OO way ?

 

[David Browne]

Recently, I tried to extent class string (it could have much more
features), and ups - "cannot derive from sealed class string", so I
looked around in some groups, and, yes, I found every time the comment
that classes string and even sytem.text.stringbuilders ARE sealed.
While I can understand this for class string (it is a non-modificable,
immutuable string), I was very suprised as I see this for class
stringbuilder.

String and StringBuilder are just special.
Performance considerations vastly outweigh extensibility or OO purity for
these types.

In C++ std:string's member functions are not virtual. Same reason. Of
course C++ has templates so you have some extra options for extensibility.

David

 

[Nico Vrouwe]

Hi,

It's not just String and StringBuilder that are special.
I noticed that for example DirectoryInfo is sealed as well

/Nico

 

[Julie]

Recently, I tried to extent class string (it could have much more
features), and ups - "cannot derive from sealed class string", so I
looked around in some groups, and, yes, I found every time the comment
that classes string and even sytem.text.stringbuilders ARE sealed.
While I can understand this for class string (it is a non-modificable,
immutuable string), I was very suprised as I see this for class
stringbuilder.

Of couse, performance optimization is one thing, but how the hell I
could extent string funcionality of .NET ? Write a wrapper class and
forward all methods or what ? That would have to do nothing with
object-orientation, and, when learning a new language, I would not
make two steps backward in design questions...

Sorry, but this is my first contact with C# (I'm coming from C++), and
I'm already shocked. I'm excited what other surprises C# would bring
for me

So please tell me, are there any further reasons why they don't allow
to inherit from both classes, are there any other similar classes or
proposals to extent string functionality in an OO way ?

I'm often frustrated w/ the same.

Personally, I think that sealed leads to all sorts of problems for users of the
library. My thoughts are that if a designer seals a class for performance
reasons, they should also offer a *non-sealed* version of the class that can be
extended by the user, w/ the expected degradation in performance.

So, if String and StringBuilder are sealed, then the designers should have
included ExtendableString and ExtendableStringBuilder that provides for
derivation.

Short-sighted design in my view.

 

[mikeb]

Recently, I tried to extent class string (it could have much more
features), and ups - "cannot derive from sealed class string", so I
looked around in some groups, and, yes, I found every time the comment
that classes string and even sytem.text.stringbuilders ARE sealed.
While I can understand this for class string (it is a non-modificable,
immutuable string), I was very suprised as I see this for class
stringbuilder.

The String class being sealed has nothing to do with the fact that
strings are immutable.

Of couse, performance optimization is one thing, but how the hell I
could extent string funcionality of .NET ? Write a wrapper class and
forward all methods or what ? That would have to do nothing with
object-orientation, and, when learning a new language, I would not
make two steps backward in design questions...

Sorry, but this is my first contact with C# (I'm coming from C++), and
I'm already shocked. I'm excited what other surprises C# would bring
for me

So please tell me, are there any further reasons why they don't allow
to inherit from both classes, are there any other similar classes or
proposals to extent string functionality in an OO way ?

As far as I know, performance is the only reason to seal a class. I
suppose that MS decided that these classes were so fundamental and so
widely used that performance was seen as more important than extensibility.

A wrapper class is one way to provide a sort of extensibility to the
String class. What seems to be more commonly done is a utility class
that contains a bunch of static methods that manipulate strings.
Neither is desirable from an OOP point of view, but the OOP path has
been closed off...

 

[Sherif ElMetainy]

Hello

Having 2 versions of a class (sealed and non-sealed) would create a lot of
confusion for developers, specially with a class as common and important as
the string class.
To make your own string maniplation methods, you can create a class with
static methods that manipulates strings.
The designers of .NET framework saw that since strings are used in almost
all progams they had to be optimized.

Best regards,
Sherif

 

[Sherif ElMetainy]

Hello

I think there are very rare situations that you need to inherit from the
string class. Personally I can't think of any. If you mean adding string
manipulation functions, then inheritance will create a problem. Suppose the
string class was not sealed, and you create the following class that has a
mehtod to reverse characters in the string.
class MyString : String {
public MyString Reverse() { // code to reverse the string}
}

Your problem will be that Reverse can only applied to instances MyString
class, but you should be able to reverse an instance of the String class as
well, so it makes more sense from OOP point of view to have a static method
somewhere to reverse the string.

class MyStringHelper {
public static String Reverse(String s) { // code goes here }
}

The second problem is that all .NET framework and 3rd party class that
return strings will return a System.String instance not a MyString. So you
will have a static method (type casting overloading is a static method) to
convert to MyString so that you can apply Reverse. This means performance
lost from .NET's side (because of not sealing) and your side (because of
conversions).

So if there is a situation (that I can't think of) where you need to inherit
from the string class, it is likely to be very rare, and since strings are
used in 99.999% of programs, so it is better to optimize it.

Best regards,
Sherif

 

[Julie]

Hello

Having 2 versions of a class (sealed and non-sealed) would create a lot of
confusion for developers, specially with a class as common and important as
the string class.
To make your own string maniplation methods, you can create a class with
static methods that manipulates strings.
The designers of .NET framework saw that since strings are used in almost
all progams they had to be optimized.

Best regards,
Sherif

String is maybe not the best example.

However, consider Convert. Very useful for providing conversions from
arbitrary to known types -- *but*, it is _sealed_. Now, if I create a new
type, there is no way to extend Convert to support it -- meaning I have to
create a completely new class or use some other traditional method.

Chew on that and let me know what you think.

 

[mikeb]

String is maybe not the best example.

However, consider Convert. Very useful for providing conversions from
arbitrary to known types -- *but*, it is _sealed_. Now, if I create a new
type, there is no way to extend Convert to support it -- meaning I have to
create a completely new class or use some other traditional method.

Chew on that and let me know what you think.

The Convert class is probably not a good example either, I think. All
of its methods are static, so you don't buy much by inheriting from it.

 

[Ravichandran J.V.]

I agree. The chances are very rare that you may want to extend the
existing functionalities unless you have missed something that already
exists. And yes, the string class itself is sealed because it is
immutable.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

 

[Sherif ElMetainy]

Hello

As mike said, Convert is also not a good example, since it exposes only
static methods, and you can make your type use convert by implementing
IConvertible interface. However I agree that sealed is sometimes
frustrating. But the post was about the String and StringBuilder classes,
where it is right to make it sealed.

Best regards,
Sherif