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,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 2B5F3BC69 for ; Thu, 18 Oct 2007 16:18:54 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAN0HF0dCm3xr/2dsb2JhbACCPTWNQQ X-IronPort-AV: E=Sophos;i="4.21,295,1188770400"; d="scan'208,217";a="3197141" Received: from janestcapital.com (HELO smtp.janestcapital.com) ([66.155.124.107]) by mail1-smtp-roc.national.inria.fr with ESMTP; 18 Oct 2007 16:18:53 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id AB4A089C; Thu, 18 Oct 2007 10:18:50 -0400 Message-ID: <47176B4A.5000807@janestcapital.com> Date: Thu, 18 Oct 2007 10:18:50 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dario Teixeira Cc: Robert Fischer , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Smells like duck-typing References: <377673.31302.qm@web54602.mail.re2.yahoo.com> In-Reply-To: <377673.31302.qm@web54602.mail.re2.yahoo.com> Content-Type: multipart/alternative; boundary="------------070504050306040704030303" X-Spam: no; 0.00; wrote:01 wrote:01 typing:01 typing:01 caml-list:01 formalism:01 formalism:01 precisely:01 precisely:01 data:02 data:02 defined:02 defined:02 seems:03 seems:03 This is a multi-part message in MIME format. --------------070504050306040704030303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dario Teixeira wrote: >Hi, > > > >>That seems backwards from the way OO inheritance is supposed to work. >>You don't go from a more feature-rich case to a less feature-rich case >>-- it's the other way around. >> >> > >Of course it is -- that is precisely why inheritance is the wrong >formalism for my problem! What I need is a "reverse inheritance" >formalism, where a fully defined data structure sits at the root, >and whose descendants are PRUNED versions of the parent. > > The problem with this is that it violates one of the assumptions of typing, that if type A is (also) a type B, than anywhere you can use a type B, you can also use a type A. This isn't an assumption limited to object oriented languages. And this isn't true in your example- if type A is lacking members type B has, then it's possible to write situations where a "real" type B can be used, but not a type A- just use a field of type B that type A doesn't have. I think I'd recommend rethinking your approach to the problem. Brian --------------070504050306040704030303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dario Teixeira wrote:

Hi,

That seems backwards from the way OO inheritance is supposed to work.  
You don't go from a more feature-rich case to a less feature-rich case 
-- it's the other way around.


Of course it is -- that is precisely why inheritance is the wrong
formalism for my problem!  What I need is a "reverse inheritance"
formalism, where a fully defined data structure sits at the root,
and whose descendants are PRUNED versions of the parent.

The problem with this is that it violates one of the assumptions of typing, that if type A is (also) a type B, than anywhere you can use a type B, you can also use a type A. This isn't an assumption limited to object oriented languages. And this isn't true in your example- if type A is lacking members type B has, then it's possible to write situations where a "real" type B can be used, but not a type A- just use a field of type B that type A doesn't have.

I think I'd recommend rethinking your approach to the problem.

Brian

--------------070504050306040704030303--