Sealed

[Hilton]

Ditto. C# improved on Java by making *methods* non-virtual by default -
I'd have thought that making classes sealed by default would have been
the logical next step.

I for one wish the "sealed" keyword on a class didn't exist. Why can I not
have:

class NamedThread : Thread
{
string name;
:
}

Please help me understand why any class would be sealed. You don't want to
expose stuff to the 'outside' world, fine, don't do it, but why can I not
add a name or tag to an object? To me, it just doesn't make sense and
breaks the whole notion of C#'s object programming.

Now, once you have justified the "sealed" keyword, explain to me a better
way of finding which thread is still running when I close my app versus
MessageBox.Show (thread.Name).

Thanks,

Hilton

 

[Tom Dacon]

I guess they figure that not everyone would subclass the Thread class so
benignly.

Tom Dacon
Dacon Software Consulting

 

[Jack White]

Please help me understand why any class would be sealed. You don't want

to expose stuff to the 'outside' world, fine, don't do it, but why can I
not add a name or tag to an object? To me, it just doesn't make sense and
breaks the whole notion of C#'s object programming.

I agree. Perhaps there's some pedantic reason for it (beyond trying to
prevent someone from leveraging your intellectual property), but if so then
it escapes me. In fact, if OOP is modelled after an "object" in the real
world where any object can be enhanced, decorated, altered, etc.(without
considering any physical limitations or practicalities that may be
involved), then in the virtual world where anything goes, there shouldn't be
any limitations at all. Note BTW that I've read it can improve performance
in some cases but in a general purpose library which is what the.NET
framework really is, this is not a satisfactory reason, especially when most
sealed classes I've seen don't qualify on that score (and I've been burned
by it as well).

Now, once you have justified the "sealed" keyword, explain to me a better
way of finding which thread is still running when I close my app versus
MessageBox.Show (thread.Name).

What's wrong with the native "Thread.Name" property

 

[not_a_commie]

I agree. Perhaps there's some pedantic reason for it (beyond trying to

prevent someone from leveraging your intellectual property),

Well, here's one reason I needed a sealed class today.

I have class public Event which contains a string name and a few other
things.
I have class public EventArgs which the user subclasses to specify
events.
I have class private EventInstance which contains one of each of the
above and is queued in my event engine.
In my event handling engine, I have to throw out EventInstance objects
that are equal.
My EventInstances are equal if my Event.name is equal and
EventArgs.Equals is true. I don't care about the other Event
properties simply because I know what they are and they are not
quickly comparable. If I let the other programmers extend Event,
though, they could easily screw up the system and be confused as to
why some of their events that they were expecting never showed up.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I for one wish the "sealed" keyword on a class didn't exist. Why can I not
have:

class NamedThread : Thread
{
string name;
:
}

Please help me understand why any class would be sealed. You don't want to
expose stuff to the 'outside' world, fine, don't do it, but why can I not
add a name or tag to an object? To me, it just doesn't make sense and
breaks the whole notion of C#'s object programming.

Now, once you have justified the "sealed" keyword, explain to me a better
way of finding which thread is still running when I close my app versus
MessageBox.Show (thread.Name).

Thanks,

Hilton

Some classes uses members marked as internal to communicate with other
classes in the same assembly. If you inherit from such a class, you
can't access those members, so you might not be able to use the class
correctly. By sealing the class, it can't be inherited by someone who
doesn't realise that it's not possible to implement a subclass currectly.

 

[Hilton]

What's wrong with the native "Thread.Name" property

Sorry, I forgot to mention I come from the Compact Framework land and Thread
is *really* watered down especially in CF 1 which our app is targetted for
(so that it runs on practically all Pocket PCs).

Hilton

 

[Jon Skeet [C# MVP]]

I for one wish the "sealed" keyword on a class didn't exist. Why can I not
have:

class NamedThread : Thread
{
string name;
:
}

Please help me understand why any class would be sealed. You don't want to
expose stuff to the 'outside' world, fine, don't do it, but why can I not
add a name or tag to an object? To me, it just doesn't make sense and
breaks the whole notion of C#'s object programming.

Inheritance should not be used lightly. Designing a class to take part
in inheritance takes a lot more effort than designing one which will
never be derived from. See
http://msmvps.com/jon.skeet/archive/2006/03/04/inheritancetax.aspx
for more on this.

 

[Chris Nahr]

I for one wish the "sealed" keyword on a class didn't exist. Why can I not
have:

class NamedThread : Thread
{
string name;
:
}

The problem with inheritance is the possibility to totally screw up
the functionality of a class, and/or confuse the user who now must
become an expert in both the base and derived class to use them
correctly.

But it's true that it's often desirable to just add some small bits of
functionality that don't affect anything else about the class, as in
your example. For that purpose .NET 3.5 (or whatever it's going to be
called -- the version that will include LINQ) will offer so-called
"extension methods": You don't have to declare a derived type,
instead you just declare a static method with an explicit "this"
parameter that you can now call as if it was defined in the class!

public static class ThreadExtension {

private Dictionary<Thread, String> _names =
new Dictionary<Thread, String>();

public static string Name(this Thread thread) {
get {
string name;
if (this._names.TryGetValue(thread, out name))
return name;
else
return "";
}
set { this._names[thread] = value; }
}
}

And the use for a given variable of type Thread would be simply:

thread.Name = "WorkerThread";
Console.WriteLine(thread.Name);

Okay, you should use weak references for the Thread keys in this case,
and I don't actually know if the extension methods feature will cover
properties... but you get the idea. I think this should alleviate
most of the common "I want to derive but can't" complaints.