Gregory Morrisett wrote:

>
>There's another option that you didn't mention which is the approach
>taken by Ada:  Have a notion of "private" types in interfaces, e.g.
>
>  type t
>  [private t = int]
>
>The client is type-checked with t treated abstractly, but the 
>compiler can then specialize the client knowing what the implementation
>of t is.  Of course, by leaking this information into the interface,
>you're effectively losing separate compilation in the sense that
>if the implementation of t changes, then its interface must also
>change and all clients must then be (potentially) re-compiled.  
>
Ocaml object system does this. Very confusing it is too,
seeing the private data in the interface .. but it is a good system,
because it is possible to abstract that data away by a further
abstraction. A large class of clients can work solely with the
abstraction .. not all because of the covariance problem ..
and those that can don't need recompilation when the representation
changes.

The biggest pain in this model is that one has to cut and paste
a lot during development... and also the lack of inter-recursion
between classes and type means you have to encode the abstraction
as a parameterised class type and then instantiate it within
the type recursion.

But the beauty of it is that at the cost of one pointer
(to the object) the abstraction allows intermodule
recursion.. the order of class compilation is irrelevant
provided only that the abstractions are introduced first.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
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