[Mono-list] 3 TODOs in Threading namespace almost completed

Ben Maurer 05mauben@hawken.edu
Tue, 16 Mar 2004 08:06:55 -0500


Actually, not all classes have to have a constructor. Look at a class
generated by:
Public Module Module1
   ' I do not know enough visual basic to code more ;-)
End Module

(ugh, vb.net).

C# will also have this sorta thingy in 2.0.

I would caution that it is easy to type the following:

public abstract class Foo {
    public Foo () { }
} 

However, this is not signature compat with ms.net. They always do
`protected', as you mentioned. Although there is not really a problem
wrt to running problems, it is an api difference, and we should not do
it. It will also make the class status pages yell.

>>> Jonathan Pryor <jonpryor@vt.edu> 03/16/04 07:47 AM >>>
On Tue, 2004-03-16 at 04:37, Mr. Deepak P N wrote:
<snip/>
> 	Since the WaitHandle class is an abstract class, we obviously
cannot
> instantiate an instance of its type.  So, how can there be an
> implementation of a constructor.

Simple.  The fact that a class is abstract has NO bearing on whether it
can have constructors.  An abstract class just cannot be directly
instantiated, but concrete subclasses can be, and they will need to
invoke the abstract classes constructor.

All classes have at least one constructor, even if it's the
compiler-generated default constructor, so all derived class
constructors will *always* invoke their base class constructor,
regardless of the abstract status of the base class.

I will admit that it doesn't make sense to have a public constructor on
an abstract class, which is why abstract class constructors are
typically protected, to further emphasize that the class must be derived
from.  It's still *valid* to have public constructors on abstract
classes.

> 	Even the MSDN documentation seems to mislead us by saying that
> WaitHadle() constructor Initializes a new instance of the WaitHandle
> class.

They're not misleading you.  WaitHandle has a constructor.

The WaitHandle constructor would be responsible for creating the
underlying (OS-native) semaphore/critical-section/lock.  Sub-classes
would override the various virtual/abstract functions (Close(),
WaitOne(), etc.), to change behavior as they see fit, but base their
behavior on the lock OS-lock held by the WaitHandle class.

The WaitHandle finalizer would be responsible for freeing the unmanaged
resources allocated in the constructor.  This keeps things sane, as all
resource acquisition and release is done in the same class.

 - Jon


_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list