From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA29094; Fri, 8 Nov 2002 20:59:54 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA27967 for ; Fri, 8 Nov 2002 20:59:53 +0100 (MET) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from hod.void.org (p5085DA2D.dip.t-dialin.net [80.133.218.45]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gA8Jxp517967 for ; Fri, 8 Nov 2002 20:59:52 +0100 (MET) Received: (from mamous@localhost) by hod.void.org (8.9.3/8.9.3) id TAA01497; Fri, 8 Nov 2002 19:59:46 GMT X-Authentication-Warning: hod.void.org: mamous set sender to leypold@informatik.uni-tuebingen.de using -f From: "M E Leypold @ labnet" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15820.6065.703831.492860@hod.void.org> Date: Fri, 8 Nov 2002 20:59:45 +0100 To: mwohlwend@web.de Cc: caml-list@inria.fr Subject: Re: [Caml-list] What are Classes for in O'Caml? In-Reply-To: <200211081445.29249.mwohlwend@web.de> References: <200211081324.IAA23597@apakabar.cc.columbia.edu> <200211081445.29249.mwohlwend@web.de> X-Mailer: VM 7.00 under Emacs 20.4.1 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Michael Wohlwend writes: > On Freitag, 8. November 2002 14:24, Oleg wrote: > > I'm curious as to what classes are for in O'Caml (in view of the > > fact that it already has abstract data types) ? > Has somone found a *best* solution (for his tasks) to combine them > (classes und modules) or is it really just a matter of taste? The following is only a suggestion: - Modules are units of compilation, hide away implemantation details and capsule namespaces. In a sense they are 'compile-time constructs'. - ADT's -- just what you should use to represent your data. Always (well: almost) use abstractions, that is, hide representation details and make operations available only by procdures / functions. Strongly related ADTs (i.e. vectors and matrices) which need to know each others representation should go into one module, but not strongly related ADTs into different modules. Note, that ADTs are _values_. - Classes, well, let's talk about objects (in my book classes are only a method to get objects ...): Objects are storage for state. Note: an object might contain state A and later state B. Applying a similar sentence to the type list doesn't make sense: You have either list A (one value) or list B (another value). There is no later time: When the name get's bound, it becomes a symbol for that value until it goes out of scope [*]. Objects make sense, when you want to have operations that do destruktive update (recycle the memory representation of their input to get the output). And this is useful to encapsule program external state (Printer, Filesystem, ...), where the old state is also lost after an operation [**]. Hope that makes sense to anyone. Regards -- Markus [*] I know, ML has imperative features. I'm talking about funktional programming here (pushing around _values_, not: "updating variables" or "updating memory locations"). Object orientation (in a sense) is really an imperative programming style :-). [**] Mercury has a special 'unique' spezifier for this kind of values, which pass into an operation and might not be referred to afterwards. This way Mercury deals with state changes in the outside world (I/O) in a purely functional way. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners