Date: Fri, 05 Nov 1999 19:49:11 +0100
From: "Francisco Valverde Albacete" <fva@tsc.uc3m.es>
To: Mark Engelberg <mark.engelberg@bigfoot.com>
Subject: Re: Classes AND Modules? What's the point?
Hi,
[Resumé en Fran=E7ais à 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... Rea=
d 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 usefu=
l,
> 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 defi=
ne 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 constru=
ctors,
do pattern matching and the sort of niceties you'd expect of functional d=
ata
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 loca=
l
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 finite=
ly
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 the=
m
co-inductively and prove properties by bisimulation...
Thus it would seem that (normal) types and classes are natural competitor=
s, and
modules are left as local contexts to bundle them all up.
> The problem is that because modules are slightly more powerful, it appe=
ars
> that the entire standard library is implemented as modules, not classes=
,
> despite the fact that this is supposed to be Object-oriented Caml! Thi=
s
> doesn't really make sense to me, because it totally hinders your abilit=
y 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, altho=
ugh 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 cont=
exts
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 t=
o me.
> Wouldn't it have made more sense to simply add the concept of inheritan=
ce 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 mod=
ules,
> 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, overwriti=
ng old
parts?)
> Can someone please explain?
I wouldn't call this an explanation, but I hope it has come in handy.
[Fran=E7ais dès ici:
Il me semble qu'il faut compare les objects aux types normaux plut=F4t qu=
'aux
modules. En vue des developpements en coalgèbres =E7a peut bien être =
le cas. Alors
on laisserait les modules comme un mecanisme de modularisation des contex=
tes.]
Regards,
Francisco Valverde
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:28 MET