Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] What are Classes for in O'Caml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: M E Leypold @ labnet <leypold@i...>
Subject: Re: [Caml-list] What are Classes for in O'Caml?


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