Thinking about it, there's at least one case where mli files are not so
useful: When you have several modules which must all comply with a
certain module type. In that case, all the mli files would be identical,
and a modification of the module type would necessitate to change all
the .mli.
What would be the best way to handle that situation?
I was thinking of making an inner module, coerce it to the desired type,
and open it afterwards, but the resulting module would still have a ref
to the inner module in its type.
E.g.:
in the file mymodule.ml <http://mymodule.ml>
-----------------------8<-------------------
module Inner = (
struct
(* implementation *)
end : Sig)
open Inner
-----------------------8<-------------------
and the file sig.mli would be the required module type.
didier
2012/10/30 Francois Berenger <berenger@riken.jp <mailto:berenger@riken.jp>>
Hello,
Here is my stupid question of the day:
what's the use of those .mli files?
Is it just to separate interface from implementation
so that the implementation of a module can be changed
without clients of its interface to have to bother?
Does it make compilation of large software faster
by allowing for more parallelization and maybe later on avoiding to
recompile some parts?
Usually I program in a pure functional style, so my modules
don't carry an internal state.
I feel like "if someone want to re-use a function, so be it".
If I really want to hide a function that I am afraid people
may call in an incorrect manner, I declare it internally
to some public function and use it correctly.
Also, maybe I only work on toy-size OCaml projects. So, I never
bothrered to create any .mli file.
I would like to know if I should bother about them.
Thanks a lot,
Francois.
--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/__arc/caml-list
<https://sympa.inria.fr/sympa/arc/caml-list>
Beginner's list: http://groups.yahoo.com/group/__ocaml_beginners
<http://groups.yahoo.com/group/ocaml_beginners>
Bug reports: http://caml.inria.fr/bin/caml-__bugs
<http://caml.inria.fr/bin/caml-bugs>