Browse thread
[Caml-list] camlimages vs. labltk
[
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: | Damien Doligez <Damien.Doligez@i...> |
| Subject: | Re: [Caml-list] naming conflicts (was: camlimages vs. labltk) |
On Sunday, March 30, 2003, at 12:38 PM, Sven Luther wrote: > But then, maybe i am just being stupid and completely misunderstand the > problem or something such, please enlighten me if this is the case. Judging from your and Chris Hecker's mail, I think it's my fault for not explaining clearly what I have in mind. Let me try again. First of all, let me say that I am looking for a complete solution to the problem, not just a quick fix that works most of the time. From this point of view, there is no difference between modules and libraries: if there are naming conflicts between modules, there will also be conflicts between libraries. I'll give two examples of what I think the problem is. First example: I am building a program D, which uses libraries B and C. B uses another library, A. C also uses another library, A. But these are not the same A, so I have a name conflict. I don't want to change the source code of B or C (because I am not the author, and updating to a new version is much harder if I use modified libraries). So I need to rename the A used by B, and I need to tell B to use A under this new name. This is why I need to rename imports as well as exports. Second example (somewhat artificial): I am doing comparative benchmarks of two versions of library A. I'd like to wrap up everything into one O'Caml program, so I need to be able to link two different versions of A, and to call them under two different names. I don't need to rename imports for this one, but I think it illustrates the problem with namespaces: are you going to demand that every author of every library uses a different namespace for each version of the library ? Now that I think about it, I think both problems could be solved by changing toplevel modules into functors (instead of modules with free variables). Then we only need a small linking language to tell which export to use to satisfy each import. With suitable defaults (an import is satisfied by the export of the same name), this could be made compatible with the current system. -- Damien ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners