From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA09876 for caml-redistribution; Fri, 4 Sep 1998 19:48:34 +0200 (MET DST)
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 PAA16586 for <caml-list@pauillac.inria.fr>; Fri, 4 Sep 1998 15:36:58 +0200 (MET DST)
Received: from nef.ens.fr (nef.ens.fr [129.199.96.12])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id PAA23711
	for <caml-list@inria.fr>; Fri, 4 Sep 1998 15:36:56 +0200 (MET DST)
Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22])
          by nef.ens.fr (8.8.8/jtpda-5.1) with ESMTP id PAA23859
          ; Fri, 4 Sep 1998 15:36:56 +0200 (MET DST)
Received: from (vouillon@localhost) by clipper.ens.fr (8.8.7/jb-1.1)
Message-ID: <19980904153653.54796@clipper.ens.fr>
Date: Fri, 4 Sep 1998 15:36:53 +0200
From: Jerome Vouillon <vouillon@clipper.ens.fr>
To: David Monniaux <monniaux@tulip.csl.sri.com>
Cc: caml-list@inria.fr
Subject: Re: inheritance for functor ?
References: <35E3C6E9.BAFFE611@univ-savoie.fr> <199809040553.WAA25004@csla.csl.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88
In-Reply-To: <199809040553.WAA25004@csla.csl.sri.com>; from David Monniaux on Thu, Sep 03, 1998 at 10:53:05PM -0700
Sender: weis

On Thu, Sep 03, 1998 at 10:53:05PM -0700, David Monniaux wrote:
> Remark: it's not possible to hide a 'new classtype' function in a
> signature. That looks useful in certain circumstances, like mlgtk with
> its classes taking a pointer into a C structure as a
> parameter. However, this is not a must at all; after all, the library
> user is supposed to be big enough to understand that some functions
> shouldn't be used, period.

Actually, this is possible: if the class is declared virtual in the
signature of the module, 'new classtype' is not exported:
    # module M = struct class c = object end end;;
    module M : sig class c : object end end
    # module M1 : sig class virtual c : object end end = M;;
    module M1 : sig class virtual c : object end end
    # new M1.c;;
    One cannot create instances of the virtual class M1.c
It is also possible to only export the class type, therefore also
preventing inheritance:
    # module M2 : sig class type c = object end end = M;;
    module M2 : sig class type c = object end end

> Talking of which, what are the perspectives on variances? In ML-gtk, I
> have classes such as button, label, all descending from
> widget. Certain functions take a widget list as an argument. The
> problem is that the user has to do the casts manually:
> 
> [((foobar constructing a button) :> widget);
>  ((foobar constructing a label) :> widget)]
> 
> which is quite heavy. Is there any way to make it look better?

It is possible to write a function that coerce an object and add it to
a list :
    # let (<<) x y = (y :> widget) :: x;;
    val << : widget list -> < .. > -> widget list = <fun>
This way, coercions are hidden:
    [] << (foobar constructing a label) << (foobar constructing a button)

-- Jerome Vouillon