Re: [Caml-list] Hiding public methods/friends methods

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Claudio Sacerdoti Coen <sacerdot@cs.unibo.it>

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

Both are not very satisfactory, for the reasons you presented.
There is a long standing discussion about the bad consequences of
friend classes in C++ also.

> (* 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
> ;;

What you should really think about is whether you need to inherit from
these classes or not.
If you do not need to inherit (which is often the case in practice),
then you can avoid the problem by exporting only constructors:

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
  val new_c : int -> ct
  val new_c' : int -> ct'
 end

These constructors can be defined in the implementation by:
  let new_c x = (new c x : c :> ct)

If you need to extend these classes (without overriding methods), you
can still define proxies afterwards. Proxies allowing method
overriding are much harder to define anyway.

Cheers,

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