From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA26661 for caml-redistribution; Sun, 7 Nov 1999 22:36:19 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA06417 for ; Fri, 5 Nov 1999 19:56:54 +0100 (MET) Received: from alcaudon.tsc.uc3m.es (alcaudon.tsc.uc3m.es [163.117.145.35]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA24671 for ; Fri, 5 Nov 1999 19:56:49 +0100 (MET) Received: from tsc.uc3m.es (garza.tsc.uc3m.es [163.117.145.203]) by alcaudon.tsc.uc3m.es (Netscape Messaging Server 3.6) with ESMTP id AAA1D92; Fri, 5 Nov 1999 19:56:43 +0100 Received: from tsc.uc3m.es (fenix [163.117.145.58]) by tsc.uc3m.es (8.9.3/8.9.3) with ESMTP id TAA23665; Fri, 5 Nov 1999 19:56:45 +0100 (MET) Message-ID: <382326A7.89245BFB@tsc.uc3m.es> Date: Fri, 05 Nov 1999 19:49:11 +0100 From: "Francisco Valverde Albacete" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Engelberg CC: caml-list@inria.fr Subject: Re: Classes AND Modules? What's the point? References: <00fb01bf2447$9ef382a0$03dedede@walldata.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsc.uc3m.es id TAA23665 Sender: weis 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