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
Real excellent object oriented source code examples of Ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-11-20 (19:28)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: Real excellent object oriented source code examples of Ocaml
> Franck wants to see real good Ocaml-3 code using all -or most of- the
> fancy advanced object-oriented features (with multiple inheritance,
> class types, functors, etc...). And I did not found much of such code
> (e.g. OO features are almost unused in the Ocaml compiler).

Not quite.  The native-code compiler uses classes, inheritance and
method overriding quite a lot to express target-specific optimizations.
(See below.)

> I am trying to show him that most of the advanced features of C++
> (templates, overloading, multiple inheritance) have their equivalent
> in Ocaml thru real source code (or that they are less useful, like C++
> overloading).

I don't want to be picky, but C++ templates are essentially unrelated to
OO programming, and correspond most closely to OCaml's functors, along
with higher-order functions and core-language polymorphism for simpler
cases.  There are plenty of nice examples of the latter (core language
polymorphism and HO functions).  As for functors, the "Set" and "Map"
modules from the standard library are good representative examples, I
think.  But then you can also add "excellent functorized source code
examples" to the subject of your message.

To follow up on Don Syme's reply, examples that demonstrate the
interest of class-based programming, as well as functorized
programming, are hard to find because most closed, stand-alone
applications do not really need classes nor functors.  That is, for
such applications, it is almost always possible to come up with a good
implementation that does not use either classes nor functors, and
indeed such "simple" implementations are often no larger and easier to
read than a class-based or heavily functorized implementation.

To feel the need for classes and functors, you need to look at
code that needs to remain flexible, extensible and reusable in
contexts that were not fully known at the time it was written.  For
instance: libraries, application frameworks, extensible applications
where new stuff will have to be added throughout the life of the

To pick my favorite example, a retargetable native-code compiler needs
to be extended each time support for a new processor is added.  The
new processor can look very much like an already supported one, in
which case it should be possible to reuse a lot of existing code; but
it can also be quite different (e.g. adding an IA32 back-end to a
compiler that supports only RISC processors), in which case it should
be possible to override significant parts of the existing code, but
without rewriting everything from scratch.  I found OCaml classes
quite effective to handle this in the ocamlopt compiler, actually more
handy than functors.

Others on this list can certainly contribute similar examples, but
they tend to be large and hard to comprehend -- just because what they
do is quite complex, and because you have to keep in mind their
evolution over time.

To come back to your original question: why don't you first look at
the kind of things your colleague does in C++ and see whether it
couldn't be expressed nicely using e.g. datatypes, pattern-matching,
polymorphism and HO functions?  Quite often, Java and C++ programmers
program in object-oriented style not because that's the best style for
their application, but because it's the only style supported by the
language.  E.g. they are used to write N+1 classes to encode a
N-constructor datatype, just because it's the way it's done in Java or

A good thing about having objects and classes in OCaml, in addition to
addressing those relatively few programming tasks that really need
them, is that when someone comes to you and asks "Can you do this
<insert tangle of classes here> in OCaml?", you can often answer "Yes,
I can do this with classes just like in your original code; but I can
also do it without, and see how much clearer and more readable it
gets".  OCaml as a rehabilitation clinic for OO programmers, if you

Good luck,

- Xavier Leroy