caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Eric Cooper <ecc@cmu.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] testing private functions with oUnit
Date: Mon, 29 Sep 2014 12:48:06 +0200	[thread overview]
Message-ID: <1411987686.5797.128.camel@e130> (raw)
In-Reply-To: <20140928230638.GT2829@cooper-siegel.org>

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

I think there is some missing functionality in OCaml: a mechanism to
grant access to something that is normally hidden. This is not only
important for unit testing but for debugging in general (remember that
even ocamldebug cannot break module abstractions).

What about this idea: modules (and only modules) can have associated
visibility attributes. These are set with the definition or in the
signature, e.g.

module Implementation { "debug" } = struct ... end

and are part of the cmi file. This imposes a restriction on the module
path - Implementation may then only occur as part of a module path if it
is explicitly allowed (e.g. that could be a command-line switch, and the
debugger would allow everything).

When using this technique, you'd normally put everything into an
Implementation sub-module that is access-protected, and you'd redefine
what is part of the regular interface:

module Implementation { "debug" } = struct ... end

import Implementation
  (* or redefine definition by definition: 
     let my_function = Implementation.my_function *)

And in the mli (which may now even be superfluous unless you want to
document the API):

val my_function : ...
module Implementation { "debug" } : sig ... end

If there was a special ANY module type that unifies with anything:

module Implementation { "debug" } : ANY

This would then simply export all definitions.

There could be additional utilities for stripping definitions with
access control tokens from the cmi files. The whole point is to grant
the developer of a certain library more rights than the user of a
library.

Gerd


Am Sonntag, den 28.09.2014, 19:06 -0400 schrieb Eric Cooper:
> I'd like to write unit tests for functions not exported in a .mli
> file.  The only way I can see is to remove the .mli file while
> building the test, so the whole .ml file is visible.  Is there a better
> way, preferably integrated with ocamlmake + findlib?
> 
> -- 
> Eric Cooper             e c c @ c m u . e d u
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2014-09-29 10:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 23:06 Eric Cooper
2014-09-28 23:12 ` Eric Cooper
2014-09-28 23:19   ` Ivan Gotovchits
2014-09-29  7:08 ` Malcolm Matalka
2014-09-29  8:03   ` Francois Berenger
2014-09-29 13:23   ` Eric Cooper
2014-09-29  8:28 ` ygrek
2014-09-29  8:50   ` Jeremie Dimino
2014-09-29 10:48 ` Gerd Stolpmann [this message]
2014-09-29 10:57   ` Gerd Stolpmann
2014-09-29 10:58   ` Maxence Guesdon
2014-09-29 12:00   ` Malcolm Matalka

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=1411987686.5797.128.camel@e130 \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=ecc@cmu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).