Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Narrowing class's public interface
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-10-13 (02:27)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Narrowing class's public interface
On Wed, 2004-10-13 at 11:43, John Prevost wrote:

> Even though we inherit float_random_variable in the type for class
> gaussian, gaussian is not, and never will be, a subtype of
> float_random_variable.  The trouble is that we have a binary method
> here. 

Indeed. More generally, objects require invariant
(or contravariant) method arguments, but almost all
'real world' problems .. and mathematics ones in particular ..
require covariant arguments, binary operators being
a special case of that.

Hence OO is useless as a general paradigm. It's a useful
technique in special cases .. in particular you get
dynamic dispatch. For example you can use OO abstraction
for device drivers because the read and write methods
only handle a *fixed* data type (characters).

Don't even both trying to make the character type polymorphic
because the theory says it can't be done. The reason is 
also easy to see, as John Provost described, but another
view of the same thing: you'd need one method for every
driver kind/character kind combination. In other words
the number of methods needed is quadratic in the subtypes,
but OO only supports linear -- you can supply a new method
for each derived 'main object' type .. which is why the method
arguments can't also be polymorphic.

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: