From: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
To: Ivan Gotovchits <ivg@ieee.org>
Cc: Alexey Egorov <electreg@list.ru>, caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Installing library with hidden modules
Date: Wed, 10 May 2017 14:43:11 +0200 [thread overview]
Message-ID: <F871634377FD475193BC89A129FA5292@erratique.ch> (raw)
In-Reply-To: <CALdWJ+xumBOYUuLh+992OeZPfPdVE-TPO_nryCqrFvD4X=VAGw@mail.gmail.com>
On Wednesday, 10 May 2017 at 14:17, Ivan Gotovchits wrote:
> So, the solution that we are using for our libraries in CMU is pretty simple, for a library/project named LIB do the following:
>
> 1. prefix all internal modules with the `LIB_`
> 2. provide a public module `LIB.ml` that reexports some of the internals
> 3. describe the public interface in `LIB.mli`
> 4. do not install `cmi` and `mli` files for the internal modules.
>
> The public interface, of course, should not mention any internals.
Yes that's exactly what I systematically do as well.
Leaving aside the prefixing, the only drawback is that for large libraries this will always link in all the internal modules even if there are some your program doesn't use. Module aliases can solve this problem but I dislike the plethora of redundant names it introduces to the end-user of the API and you are still left prefixing your internal modules with `LIB_`.
It's funny (or sad) to have that powerful module system with abstraction and name hiding capabilities in your hands and you end up having to do what you do in C to ensure naming isolation among libraries.
I hope one day we can solve this problem without having to prefix the internal modules, without force linking all the internal modules, without multiplying the names that are exposed to the end user of the API and with generated documentation navigation that exactly matches how module items are accessed in your API.
Best,
Daniel
prev parent reply other threads:[~2017-05-10 12:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-07 5:24 Alexey Egorov
2017-05-08 10:56 ` Daniel Bünzli
2017-05-08 12:49 ` Ivan Gotovchits
2017-05-09 21:01 ` Daniel Bünzli
2017-05-10 12:17 ` Ivan Gotovchits
2017-05-10 12:43 ` Daniel Bünzli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F871634377FD475193BC89A129FA5292@erratique.ch \
--to=daniel.buenzli@erratique.ch \
--cc=caml-list@inria.fr \
--cc=electreg@list.ru \
--cc=ivg@ieee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox