Re: [Caml-list] Five Questions about Objects

[Xavier Leroy <xavier.leroy@inria.fr>]

> A few questions on objects:

To complement the replies you already got:

> 2) What is the point of "class" and "new" keywords? How are they better than 
> "let" ? E.g.
> 
> let point a b = 
>   object
>     val x = a
>     val y = b
>     method get () = (x, y)
>   end;;
> 
> let my_point = point 3 7;; 
> let many_float_points = Array.make 100 (point 4.0 3.0);;
> ?

The main purpose of the class system is to support inheritance and
method overriding.  Object-oriented programming comes in two flavors:
class-based OOP, which is what all mainstream OO languages offer, and
delegation-based OOP, where there are no classes, objects are built
directly by listing their fields and methods like you suggested, and
method overriding is performed directly on objects, e.g. via a "copy
this object, replacing these methods" operation.  While there have
been some theoretical work on delegation-based OOP, I think it is fair
to say that it is less well understood than class-based OOP.

> 4) Can I construct an object that the following function f would accept?
> # let f a = a#m1 (); a#b#m2 ();;
> val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a = <fun>
> 
> I tried the obvious (to me) and it doesn't work. What is the precedence and 
> associativity of #?

# is not associative because it is not really a binary operator.  In
other terms, a#(b#m2) doesn't make sense because the right-hand side
of the # sign must be a method name, not the result of a computation.

As for your example, just read the type of f aloud: the argument to f
should be an object having at least an "m1" method and a "b" method;
"b" should return an object having at least an "m2" method.

> 5) What is the current state of marshalling objects? Is Jacques's
> patch going to be used in the upcoming O'Caml version or is it too
> untested?

It's not going in the next release because the working sources are in
"code freeze" state, meaning we fix bugs but don't add features.  It
might be merged in afterwards provided some minor technical issues are
fixed.  But at any rate this only provides a limited form of
marshalling where the program that reads back the marshalled object
must be *exactly identical* to the program that marshalled the object.
There are cases where this restriction is OK (e.g. SPMD programming),
and others where it makes object marshalling inadequate
(e.g. databases, general distributed programming).

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