From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 485567FACD for ; Mon, 29 Sep 2014 14:00:54 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=74.125.82.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 74.125.82.176 as permitted sender) identity=mailfrom; client-ip=74.125.82.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f176.google.com) identity=helo; client-ip=74.125.82.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-we0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsBAI5JKVRKfVKwm2dsb2JhbABggmvTMgKBDBYBEQEBAQEBBgsLCRQshAQBAQMBEi4BGx0BAwELBgULAxMlDwEEDxEBBQEiEyKIBwEDCQgBBJ1Ubo0igxCIXgoZJw1nhjkBEQEFDpAQB4RLBZsbgg2Ta0GFFGyCSgEBAQ X-IPAS-Result: AtsBAI5JKVRKfVKwm2dsb2JhbABggmvTMgKBDBYBEQEBAQEBBgsLCRQshAQBAQMBEi4BGx0BAwELBgULAxMlDwEEDxEBBQEiEyKIBwEDCQgBBJ1Ubo0igxCIXgoZJw1nhjkBEQEFDpAQB4RLBZsbgg2Ta0GFFGyCSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,620,1406584800"; d="scan'208";a="81262316" Received: from mail-we0-f176.google.com ([74.125.82.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Sep 2014 14:00:29 +0200 Received: by mail-we0-f176.google.com with SMTP id p10so1307380wes.35 for ; Mon, 29 Sep 2014 05:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=9aEXCUGikieFbPf5sxGBm/Nb05vCtI8ktvT4Wy0GfUA=; b=R0YV7VTfzbkdUv0h6O8bzKL3o0+Ie/7vxnCL1wGeL9uhMcm/du7JZ9GBurLYLTQh+a K2Ko+3WKzoQ4cn5B+raM8lWwtoQdZXo1pQY6Uo7JwCgUAEr7gYevEv5dHrT/GT+PBltD ++z3mBa1/CCgPjqLU9aivY+QwYsd5P7sOgWorST+gvXD4ubLtuGqshbwpaMh1em2qSZV 5wYYCkHd2ZTa0yg+66tuTR34DwaN6+9zQJj1HgbAh8s+/vH9gc3kEmwlWDbzwU4PWxiK qqAK4KSYMcAoUnLjUn0dLy6DqsSKgSVNPj1j7dhF9bOut/rkGkNSE/u1mBb5gfplTOu1 bxNg== X-Received: by 10.180.206.230 with SMTP id lr6mr47412564wic.82.1411992029586; Mon, 29 Sep 2014 05:00:29 -0700 (PDT) Received: from localhost ([2a01:7e00::f03c:91ff:fe70:2696]) by mx.google.com with ESMTPSA id i1sm5901261wix.23.2014.09.29.05.00.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Sep 2014 05:00:28 -0700 (PDT) From: Malcolm Matalka To: Gerd Stolpmann Cc: Eric Cooper , caml-list@inria.fr References: <20140928230638.GT2829@cooper-siegel.org> <1411987686.5797.128.camel@e130> Date: Mon, 29 Sep 2014 12:00:28 +0000 In-Reply-To: <1411987686.5797.128.camel@e130> (Gerd Stolpmann's message of "Mon, 29 Sep 2014 12:48:06 +0200") Message-ID: <87oatyocv7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] testing private functions with oUnit I believe .Net has the concept of visibility at the module, package, and external layer. Something like this would be nice, although I have no idea what it would look like, in Ocaml since often I want to create modules internal to a package to make the code cleaner but those functions have to be visible to everyone. But, IMO, even though it would be nice I don't think it's stopping myself from writing anything. Gerd Stolpmann writes: > 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 >>