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 VAA29930; Fri, 8 Nov 2002 21:34:45 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 VAA29503 for ; Fri, 8 Nov 2002 21:34:43 +0100 (MET) Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id gA8KYgD06173 for ; Fri, 8 Nov 2002 21:34:43 +0100 (MET) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Fri, 8 Nov 2002 14:34:41 -0600 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Fri, 8 Nov 2002 14:34:41 -0600 Date: Fri, 8 Nov 2002 14:41:01 -0600 (CST) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: "M E Leypold @ labnet" cc: , Subject: Re: [Caml-list] What are Classes for in O'Caml? In-Reply-To: <15820.6065.703831.492860@hod.void.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Nov 2002 20:34:41.0620 (UTC) FILETIME=[43F2E140:01C28766] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I'm still a newbie at Ocaml- but here's my $0.02: OO programming has a classic analysis technique- 'is a' relationships vr.s 'has a' relationships. If a relationship is an 'is a' relationship, you use object inheritance, if it's a 'has a' relationship, you use a member variable. Caml's ADT concept adds a third case- the 'of' case. Think about it- what does 'a list mean as a type? It means it's a list *of* objects of type a. Java doesn't have a natural way to express the 'of' relationship between two types. So you end up with collections only handling Objects (abusing the has-a relationship), and lots of unnecessary typecasting (subverting the type system, and causing run time errors and hard to find bugs). C++ introduced Templates to express the 'of' relationship, but (IMHO) did it nearly perfectly bad. I can't think of many ways to make C++ templates worse. Just like you can (and many people do) confuse is-a and has-a relationships, and make it (more or less) work. Likewise, you can swap either of them in for of relationships and make it (more or less) work. But there's a difference between 'workable (more or less)' and 'correct'. I like languages where I can express what I mean, and use the right language construct for the right relationship. I'm probably not giving ADTs the credit here they really deserve. But that's how I've been thinking of them. Brian On Fri, 8 Nov 2002, M E Leypold @ labnet wrote: > > > 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 > ------------------- 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