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

["Francisco Valverde Albacete" <fva@tsc.uc3m.es>]

Hi,

[Resumé en Français à la fin]

I have also been wondering at this question and haven't found and answer yet but
I am willing to share a couple of thoughts with you, if you'd like... Read on,
please!

Mark Engelberg wrote:

> 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.

Let me explain my prejudices as I used to have them some months ago:

- modules are for functional, stateless Abstract Data Types: you can define the
main sort of the Type (even polymorphic ones) and add all orbiting sorts you
need and so forth. You can even define them inductively with data constructors,
do pattern matching and the sort of niceties you'd expect of functional data
types and you can define observer functions and de-structors (though you'd call
them projections or coprojections and whatever)

- classes and objects are for anything resembling *states*: you pass the initial
state on creation, then mutate and observe it through observers. You have *one*
constructor through the "new" function, and destruction is done (thank's god) by
the GC.

Now, picture trying to set a state on a module (mainly defining some local
initialized variables) and keep several instances of this state... Nasty & ugly,
right? That's what we improved in from Camllight to OCaml: nice ways for doing
stateful things.

Now, picture bundling up an abstraction through a class without resorting to
modules. You can't even define types! (This used to be so, but maybe it's
changing in the next release?) Also, the name "constructor" doesn't even mean
the same for types and classes... I can't even imagine doing *everything* with
classes! A very customizable facility is what with modules (somewhere in the way
from CAML to Camlight 0.7)

Now, this is my new vision: some algebraic work by a guy called B. Jacobs
suggests that:
- "normal" types admit initial algebras as models, their terms are finitely
generable from constructors and you can prove and define properties by
structural induction;

- "class" types admit *final coalgebras* as models, they are not finitely
generable but they are models for infinite structures, you can define them
co-inductively and prove properties by bisimulation...

Thus it would seem that (normal) types and classes are natural competitors, and
modules are left as local contexts to bundle them all up.

> 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!  This
> doesn't really make sense to me, because it totally hinders your ability to
> subclass and extend the default libraries.

I was one of the users who missed modules in old CAML and very much like modules
in Ocaml (and Camlight) as a means to structure code and libraries, although I
have been unable yet to obtain such good use out of classes and objects (mainly
because I think I don't understand row polymorphism).

But the point is *I want modules to structure code!*. They are local contexts
whereas classes are not. You still have to define modules to contain your
classes!

> 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?  Or if the focus is
> intended to gradually shift in the direction of classes rather than modules,
> shouldn't the standard libraries reflect this?

I would still like to see modules as first values (recursion & the like) but
this seems out of the frontiers of abstract language science for the time being.

And yes!, I'd like inheritance in modules, but this looks as if would not work
like we are used to with classes (inheriting parts of contexts, overwriting old
parts?)

> Can someone please explain?

I wouldn't call this an explanation, but I hope it has come in handy.

[Français dès ici:

Il me semble qu'il faut compare les objects aux types normaux plutôt qu'aux
modules. En vue des developpements en coalgèbres ça peut bien être le cas. Alors
on laisserait les modules comme un mecanisme de modularisation des contextes.]

Regards,

            Francisco Valverde