From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 11C81BBAF for ; Tue, 18 Nov 2008 13:32:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCAMxEIklQRFuwgWdsb2JhbACTWQEBFiK+HIJ5 X-IronPort-AV: E=Sophos;i="4.33,624,1220220000"; d="scan'208";a="19289480" Received: from furbychan.cocan.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 18 Nov 2008 13:32:33 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1L2Pkt-0003yn-Uh; Tue, 18 Nov 2008 12:32:31 +0000 Date: Tue, 18 Nov 2008 12:32:31 +0000 To: David Teller Cc: Daniel =?iso-8859-1?Q?B=FCnzli?= , OCaml List Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included Message-ID: <20081118123231.GA15110@annexia.org> References: <1227002178.6170.25.camel@Blefuscu> <20081118100625.GA25627@annexia.org> <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> <1227010539.6170.72.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1227010539.6170.72.camel@Blefuscu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; ocaml:01 0100,:01 ocaml:01 lablgtk:01 ifdef:01 lablgtk:01 gmisc:01 gmisc:01 -pp:01 cpp:01 churn:98 wrote:01 preprocessor:01 caml-list:01 breaks:02 On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote: > Do you see any better way of managing the complexity of all this? I'm still not getting where the benefit of having this hierarchy is, except that it adds a Java-like complexity and will create hard-to-manage churn if a module ever moves. API changes are handled really badly in OCaml, ironically because of the lack of a textual preprocessor. You can't just write this every time lablgtk / calendar / latest culprit decides to change their API: #ifdef LABLGTK < 210 let icon = GMisc.image () in icon#set_stock icon_type ~size:size; icon #else let icon = GMisc.image () in icon#set_stock `DIALOG_ERROR; icon#set_icon_size `DIALOG; icon #endif (Well, you can run -pp cpp, but that breaks other stuff) Rich. -- Richard Jones Red Hat