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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 3621E7F249 for ; Wed, 31 Oct 2012 22:29:53 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoBAMeXkVDAbSoIe2dsb2JhbABEhhe9SCMBARYmBCOCHgEBBAEjVhALGgImAgIhNgYTh3QDCQYEqDyJIA2JVIEgiXFnhSgyYQOUIYFVhWmFSIgB X-IronPort-AV: E=Sophos;i="4.80,688,1344204000"; d="scan'208";a="161057281" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2012 22:29:52 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from [192.168.1.9] (178-26-88-14-dynip.superkabel.de [178.26.88.14]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q9VLTnQN008769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Oct 2012 22:29:50 +0100 References: <508F22BD.7010103@riken.jp> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <94654D4E-20EE-4690-91EA-9BBD1CF111C5@first.in-berlin.de> Cc: Francois Berenger , caml-list X-Mailer: iPad Mail (10A403) From: Oliver Bandel Date: Wed, 31 Oct 2012 22:30:07 +0100 To: Didier Cassirame X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] Why should I use .mli files? Am 30.10.2012 um 16:52 schrieb Didier Cassirame : >=20 > Thinking about it, there's at least one case where mli files are not so u= seful: When you have several modules which must all comply with a certain m= odule type. In that case, all the mli files would be identical, and a modif= ication of the module type would necessitate to change all the .mli. Sounds like you reformulated an advantagenas being a disadvantage. If someone changes a type of a module by accident, it,will pop up as problem. Also I wonder, if a type that is used by other modules might not also need to change the mplementation. I think it depends on the kind of change. Maybe you can provide an example. Somehow the discussion looks a bit like changing the interface often to be a sport for programmers. I remember times, when it was a good idea tomchange interfaces as seldom as possible. But modern times bring modern behaviour. Maybe soon there will be a fast-interface-change contest. One big advantage of mli-files is, to carve the interface in stone. So even I mostly used OCaml only for my own small projects, in a big project with many developers, it would make sense that the team will plan the interface, and when the decisionis done, the project leader or a certain person who is responsible for mantaining the nterfaces, will create the file and has rw-permissions, and the other developers only have group-readability. So then they have to use the interface as it was agreed upon. And the one who wants to implement furthe things can omit the mli file for = a while, but if the code does not compile with the official mli-file, the code will be rejected. I think this is a valuable tool, the mli can provide clear interfaces, and this is working well wirh many developers. And if changing of intefc=C3=BCace really can't be avoided, it will need a team meeting on intercace change. Thats totally different to lets-change-they-interface-as-often-as-possible contest behaviour. Best wishes, Oliver