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=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 1AA5DBC6C for ; Tue, 5 Feb 2008 10:51:39 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI/Ap0fUVZgL/2dsb2JhbACtAg X-IronPort-AV: E=Sophos;i="4.25,306,1199660400"; d="scan'208";a="6903498" Received: from hades.snarc.org ([212.85.152.11]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 10:51:38 +0100 Received: by hades.snarc.org (Postfix, from userid 1000) id 4DE141B482; Tue, 5 Feb 2008 10:51:37 +0100 (CET) Date: Tue, 5 Feb 2008 10:51:37 +0100 To: =?iso-8859-1?Q?B=FCnzli?= Daniel Cc: caml-list caml-list Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API Message-ID: <20080205095137.GA3573@snarc.org> References: <52FAAA41-5B70-4F87-9F83-B8A96EA48D34@erratique.ch> <200801301035.31447.jon@ffconsultancy.com> <47A7EDFE.1050805@frisch.fr> <36788A32-5BAC-4D57-9D0A-B9A20A49536F@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <36788A32-5BAC-4D57-9D0A-B9A20A49536F@erratique.ch> X-Warning: Email may contain unsmilyfied humor and/or satire. User-Agent: Mutt/1.5.16 (2007-06-11) From: tab@snarc.org (Vincent Hanquez) X-Spam: no; 0.00; 0100,:01 bunzli:01 libs:01 variants:01 variants:01 polluted:01 polymorphic:01 polymorphic:01 wrote:01 caml-list:01 variant:02 api:02 library:03 daniel:04 types:05 On Tue, Feb 05, 2008 at 09:36:02AM +0100, Bünzli Daniel wrote: >> - having a common spec for several libs makes more sense if they can share >> common types; maybe you should use polymorphic variants instead of regular >> ones? > > Agreed. In xmlm these variants become polymorphic in the next version. that's really a bad idea; As a user of xmlm, I hope you're going to re-consider. the polymorphic variant namespace is so easily polluted by random "value" that library should never use them or at least doesn't advertise them as public interface. -- Vincent Hanquez