From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA13101; Thu, 31 Jan 2002 02:01:28 +0100 (MET)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA13338 for <caml-list@pauillac.inria.fr>; Thu, 31 Jan 2002 02:01:27 +0100 (MET)
Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250])
	by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g0V11Pv24175
	for <caml-list@inria.fr>; Thu, 31 Jan 2002 02:01:26 +0100 (MET)
Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17])
	by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id JAA24832;
	Thu, 31 Jan 2002 09:09:56 +0900
To: sacerdot@cs.unibo.it
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Hiding public methods/friends methods
In-Reply-To: <20020122182621.B8021@cs.unibo.it>
References: <20020122182621.B8021@cs.unibo.it>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20020131090912V.garrigue@kurims.kyoto-u.ac.jp>
Date: Thu, 31 Jan 2002 09:09:12 +0900
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
X-Dispatcher: imput version 20000228(IM140)
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

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