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.0 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS 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 C1617BC69 for ; Thu, 18 Oct 2007 18:24:34 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHElF0fOvjGuoWdsb2JhbACOTQIBAQIFBAYJCAEXgSc X-IronPort-AV: E=Sophos;i="4.21,296,1188770400"; d="scan'208";a="18231711" Received: from web54604.mail.re2.yahoo.com ([206.190.49.174]) by mail4-smtp-sop.national.inria.fr with SMTP; 18 Oct 2007 18:24:34 +0200 Received: (qmail 37545 invoked by uid 60001); 18 Oct 2007 16:24:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=JbG/JoAMuYFbnKY4AJnZbZnUCzcecQxJ9gJwqTdM3ltDYRizyiowmfCR/wdKuIxKRGynZSeVBBrxaJLqFlWnEFdyc4MLA23jZZcRsTVpple+hs2bAVke6eakyWUzS9pXZt45Ud3aQL87onIVrlUpNilZtYn6ZcKD+6/9IYt46MM=; X-YMail-OSG: ZERCr_cVM1lM_kmp2Ws9RUu3V.F7UHtBVKQn1cmOl2hhbZzWOFcLNOD69eTsedYRzWymD67yBVc4eJ2LY0_54QupyHf77NNexvumjMibi2h.zA98Gjc0MIdq47HuGFeyKJHizuQHsO2g4WkW8yHjUXYL Received: from [82.155.125.49] by web54604.mail.re2.yahoo.com via HTTP; Thu, 18 Oct 2007 17:24:32 BST Date: Thu, 18 Oct 2007 17:24:32 +0100 (BST) From: Dario Teixeira Subject: Re: [Caml-list] Smells like duck-typing To: caml-list@yquem.inria.fr In-Reply-To: <377673.31302.qm@web54602.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <939878.37106.qm@web54604.mail.re2.yahoo.com> X-Spam: no; 0.00; ocaml's:01 subtyping:01 semantics:01 semantics:01 cheers:01 marble:98 marble:98 carbon:98 caml-list:01 precisely:01 int:01 purely:02 defined:02 defined:02 chunk:02 Hi, (This is a collective reply to all the issues that were raised by my previous message; sorry if I don't answer each message individually). I made the early "reverse inheritance" suggestion somewhat facetiously, but judging from the replies, there was a certain amount of confusion about what I meant. I'll try to describe what I have in mind. I'll do it by modelling the problem in an imaginary OCaml-derived language that features "reverse inheritance". Please read on: The "story" class is one that is fully defined. Think of it as a raw block of marble from which the non-important pieces can be carved out. To avoid confusion, let's call a class of this kind a "marble-class": marble-class story (id, title, intro, body) = object method id: int = id method title: string = title method intro: string = intro method body: string = body end Now, a "full_story" is one that is also fully defined. Taking as starting point the "story" block-class previously defined, you don't need to carve out anything to obtain a full_story: marble-class full_story (id, title, intro, body) = object carves story (id, title, intro, body) end However, a "blurb_story" does introduce changes: it can be formed by taking the original story as a starting point, and removing the "body" chunk of marble. Note that I am using some new keywords: carves, removes, and CARVED: marble-class blurb_story (id, title, intro) = object carves story (id, title, intro, CARVED) removes method body end Similarly, a "fresh_story" is a story without the "id" field: marble-class fresh_story (title, intro, body) object carves story (CARVED, title, intro, body) removes method id end Now, if you think in terms of traditional inheritance, a blurb_story "B" is also a story "A", and so on (with OCaml's subtyping inheritance, the semantics are a bit different, but let's not go there right now). Therefore you would expect that any method that works on A should also work on B. But here it's precisely the opposite: anything that works on B should also work on A, but not the other way around. If the confusion is purely linguistic, then let's not call it "reverse inheritance"; let's use "marble carving" instead. (Note that for these semantics to be correct, then a carved-class is not allowed to add new methods, but only to remove existing methods from the class it is carving). Finally the big question: is this useful or even feasible to implement? Probably not. But for the problem I have at hand, this is still the modelling that best fits my mental picture of the relation between the various story types. Cheers, Dario ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html