English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [Caml-list] Some Clarifications
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-07-27 (16:23)
From: james woodyatt <jhw@w...>
Subject: Re: [Caml-list] Some Clarifications
On 27 Jul 2005, at 03:58, Jon Harrop wrote:
> Of the OCaml code which I have studied, the OCaml compilers make  
> scarce use of
> objects, the stdlib makes no use (IIRC), the third party data  
> structures and
> algorithms that I use also make no use of OO but lablgtk uses OO  
> and I have
> one friend who has tried using OO in his own OCaml work.

In the first pass through at my functioanl reactive I/O [Iom] library  
in OCaml NAE, I managed to get a lot done without using any objects.   
In general, this produced tighter code, but it was less adaptable  
than I wanted it to be, and I found it hard to reuse parts of  
reactors.  Sure, reactors themselves were highly reuseable, but I  
found myself wanting to make a framework of very similar reactors all  
built out of some common functions.  A reactor was typically written  
as a huge bundle of mutually recursive monad functions, and it was a  
major pain to separate the reusable functions from the rest of the  

In my recently announced refactoring of the [Iom] library, I found I  
could get more adaptability by using the object system.  In the new  
code, reactors can be written as classes (even pure functional  
classes) and the monad functions implemented as methods.  It makes  
the challenge of designing a general purpose reactive I/O framework a  
lot easier.  The problem of separating the reusable functions from  
the rest of the bundle is resolved by implementing a class with  
virtual methods.

I doubt this hybrid approach, combining both FP and OO, could be used  
in any other language I know about.  From my perspective, FP and OO  
are orthogonal and not mutually exclusive techniques.  Once you  
decide to use OO for what it really does, and which FP doesn't, I  
think you find that what it has to say about large-scale software  
development is a lot less than what most practitioners think.  This  
is because you're right: most programmers don't use OO because it's  
the right tool for the job; most use it because it's inappropriately  
forced on them by a language that doesn't provide reasonable  
alternatives for things that don't need OO to enable.

j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.