Re: [Caml-list] What are Classes for in O'Caml?

[Brian Hurt <brian.hurt@qlogic.com>]

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