Re: Classes AND Modules? What's the point?

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> I have spent some time this past week looking at OCaml for the first time.
> I have no previous experience with ML, but I do have a pretty good
> understanding of functional languages in principle.
> The thing that confuses me the most about OCaml is that there is a huge
> overlap between the functionality of classes and modules, with a couple of
> subtle differences.  Classes offer inheritance which is extremely useful,
> but modules have a little more typing flexibility, the ability to share
> private data among multiple structures in one package, and the ability to
> specify compilation units.

We are aware of the overlap between classes and modules, although I'm
not sure the overlap is as large as you say.  I gave an invited talk
on this topic at last ICFP; the slides are available from my home page
(http://pauillac.inria.fr/~xleroy/)

> The problem is that because modules are slightly more powerful, it appears
> that the entire standard library is implemented as modules, not classes,
> despite the fact that this is supposed to be Object-oriented Caml!

There are two reasons why the standard library is implemented without
classes.  The historical reason is that the standard library comes
straight from Caml Special Light, the ancestor of OCaml that didn't
have classes and objects yet, but already had objects.

The other reason is that I don't see any module in the standard
library (except perhaps Format) that would really benefit from being
converted into objects and classes.  For many data structures
(hash tables, stacks, etc) the class-based presentation would be no
better than the current module/abstract data type presentation.
For others (sets, maps), the class-based presentation would be less
good, e.g. with less precise static typing.

> This
> doesn't really make sense to me, because it totally hinders your ability to
> subclass and extend the default libraries.

Do you really need to?  What good would it make to subclass hash
tables as opposed to putting a hash table in a field or instance
variable of another datatype or class?  No offense intended, but
programmers with extensive C++/Java background are so used to the
inheritance hammer that they see every problem as a nail.  Inheritance
is great in some cases (I've used it in parts of the native-code
compiler and it was very nice), but in my opinion nearly useless for
simple data structures like those of the OCaml standard library.

> This weird coexistence of classes and modules just doesn't make sense to me.
> Wouldn't it have made more sense to simply add the concept of inheritance to
> modules, rather than define a new "class" construct that supports
> inheritance but not all the other features of modules?

It would make a lot of sense, but it's still an open research issue.
In particular, no-one knows yet how to "add the concept of inheritance
to modules" in a way that really reduces the overlap between classes and
modules.  (See for instance Jérôme Vouillon's paper "Using modules as
classes", http://pauillac.inria.fr/~vouillon/publi/classes.ps.gz)

> Or if the focus is
> intended to gradually shift in the direction of classes rather than modules,
> shouldn't the standard libraries reflect this?

My intention is certainly not to shift away from modules.  The way I
like to think about OCaml is that you have functions, datatypes and
modules for "everyday" programming, and classes and objects for those
programs that need them in an essential way.

- Xavier Leroy