Re: [boost] Re: Boost.Threads - thread_desc concept

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-27 13:06:26

Peter Dimov wrote:

> > implementations.  In order to have a "procedural interface" we have
> > to either make the thread_desc a structure with all public data or
> > make every method a friend.
> 
> I don't understand why, could you elaborate?

        Its a general problem with OO called the 
covariance problem.

        Suppose you have an abstraction consisting
of two types and some relations (and functions)
between them.

        If you have several implementation of each
type, say n for one, and m for the other, then
then to model the function or relation

        f: a -> b

you have to provide n * m functions. But inheritance
only allows for n+m functions. So OO is broken,
it is an utterly absurd paradigm with no sound
mathematical basis as a technique for representing
abstraction.

        Compare this with a template with 
two type arguments. That works. You just don't
get run time dispatch.

        The only OO solution to this problem is to 
give up on abstraction: you have to make one of the
types concrete.

        This is what Bill was saying when he
said that you have to make the thread_desc a structure
will all public data. Making all methods a friend
doesn't work, because it prevents adding new methods
unless you're willing to break encapsulation by adding
friend declarations to the base class.

        On the other hand, a single thread class
may appear to avoid this problem. The problem is that
it actually doesn't, if you want an abstract thread
type with relations like equality. [Equality is
an example of a binary relation, and as such
a polymorphic method with abstract arguments
cannot be implemented]

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net