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.1 required=5.0 tests=AWL,MISSING_HEADERS autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 11D0BBBCA for ; Tue, 26 Feb 2008 14:10:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADuew0fAXQInh2dsb2JhbACQZAEBAQgKKZtz X-IronPort-AV: E=Sophos;i="4.25,407,1199660400"; d="scan'208";a="23060371" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 26 Feb 2008 14:10:14 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1QDADeA027562 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 26 Feb 2008 14:10:14 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADuew0fBL1AZkmdsb2JhbACQZAEBAQEHBAYHIptz X-IronPort-AV: E=Sophos;i="4.25,407,1199660400"; d="scan'208";a="7719312" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Feb 2008 14:10:13 +0100 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.0/8.14.0) with ESMTP id m1QDADMN028915 for ; Tue, 26 Feb 2008 14:10:13 +0100 Message-ID: <47C40FB5.1090603@exalead.com> Date: Tue, 26 Feb 2008 14:10:13 +0100 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 Cc: Caml-list List Subject: Re: [Caml-list] Objects, dynamic cast, Obj.magic abuse and dragons References: <47C3F96E.4080901@exalead.com> In-Reply-To: <47C3F96E.4080901@exalead.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 47C40FB6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 evidently:01 scalable:01 parametrized:01 paramters:01 compilation:01 ...,:98 incremental:01 exception:01 exception:01 caml-list:01 constraint:01 I have found a where, for each category C (such as place or person), you add a method as_C : C in physical that throws a Class_cast_exception, and override it with a method that returns self in class C. However this means that the type C must appear in the definition of physical, which means that either (a) All categories C1, ..., Cn are defined in the same file in the same bunch of mutually-recursive class definitions; a solution evidently not scalable. (b) The physical class is parametrized by n paramters 'C1, 'C2, ... 'Cn, which must be repeated everywhere. The latter solution works for small n but the complexity of incremental maintenance is in O(n). This means that if you define your n classes in n files, you'll have to edit n files to add an (n+1)-th class. This leads me back to an idea I was talking about with Yann Régis-Gianas a few months ago : the ability to bundle type parameters as a named record and to access their components. You could write, in a file f.ml: type ''bundle := ('place, 'person, 'c3, 'c4 ...) then in physical.ml : class [F.''bundle] physical = object method as_place : raise Class_cast_exception method as_person : raise Class_cast_exception method as_c3 : raise Class_cast_exception end and in place.ml class [F.''bundle] place = object(self : 'a) constraint ''bundle.'place = 'a method as_place = self end and so on... I don't know how much sense this makes with respect to separate compilation. However, this would allow you to add a category by just editing two files. -- Berke DURAK