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