Hi,

 I would like to define a huge bunch of mutual recursive classes
 with "friends methods". (The code is automatically generated, so
 I don't mind very much an heavy coding style.)

 Of course, I can use the trick of abstracting the output type
 of all the friends methods in the signature of the module.
 Because I have lots of friends methods, though, the resulting
 .mli I get is quite confusing.

 Another solution is creating "proxy" objects (see the code below).
 But I fear the performance loss to be significant.

 Which solution is best (not withstanding performances) and why?
 (Or which is a much better solution I don't see ;-)

				Thanks in advance,
				      C.S.C.


(* This is the interface I would like to have. *)
module type MT =
 sig
  class type ct = object method get_c' : ct' method m : int end
  and ct' = object method get_c : ct method m' : int end
  class c : int -> ct
  class c' : int -> ct'
 end
;;
 
module M : MT =
 struct
  (* This is the implementation: obj and obj' are the two public methods
   * I want to hide.
   *)
  class _c (obj : int) =
   object
    method obj = obj
    method get_c' = new _c' obj
    method m = (new _c' obj)#obj'
   end
  and _c' obj =
   object
    method obj' = obj
    method get_c = new _c obj
    method m' = (new _c obj)#obj
   end

  (* Again the interface... *)
  class type ct =
   object
    method get_c' : ct'
    method m : int
   end
  and ct' =
   object
    method get_c : ct
    method m' : int
   end

  (* The two proxy objects *)
  class c obj =
   let o = new _c obj in
    object
     method get_c' = (o#get_c' : _c' :> ct')
     method m = o#m
    end

  class c' obj =
   let o = new _c' obj in
    object
     method get_c = (o#get_c : _c :> ct)
     method m' = o#m'
    end
 end
;;

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sacerdot@cs.unibo.it
http://caristudenti.cs.unibo.it/~sacerdot
----------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr