Browse thread
Extending modules and signatures
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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