Version française
Home     About     Download     Resources     Contact us    
Browse thread
Extending modules and signatures
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] Extending modules and signatures
Martin Jambon <martin.jambon@ens-lyon.org> writes:

> OK, but I think the real issue is inheritance.  In order to truly extend an
> existing module, one needs to access the private items of the inherited module
> implementation.  In order to avoid messing up with the original module's
> global variables, the inherited "module" should be more like a functor that
> would create a fresh instance of the module each time it is instantiated, just
> like classes generate objects.
>
>
> I could imagine something like this:
>
> module class A :
> sig
>   val get_x : unit -> int
> end =
> struct
>   let x = ref 123
>   let get_x () = !x
> end
>
> module class B =
> struct
>   inherit A
>   let incr_x () = incr x
> end
>
> module B1 = new module B
> module B2 = new module B
> ;;
>
> B1.incr_x ();;
> - : unit = ()
> B1.get_x ();;
> - : int = 124
> B2.get_x ();;
> - : int = 123
>
>
> Module class implementations and signatures could be conveniently created as
> whole files using new file extensions, say .mc and .mci.  These would be like
> .ml files except that they would support module class inheritance and would be
> evaluated only when they are instantiated with "new module".

Which would also need

module A1 = new module A
module A2 = new module A
A1.incr_x ()
A1.get_x;;
- : int = 124
A2.get_x ();;
- : int = 123

So you see A does not have global variables but only instance
variables. What you describe are ocaml objects. Not modules.

MfG
        Goswin