From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 51429BB9A for ; Sat, 22 Oct 2005 07:53:33 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j9M5rW5m020344 for ; Sat, 22 Oct 2005 07:53:33 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA08556 for ; Sat, 22 Oct 2005 07:53:32 +0200 (MET DST) Received: from mz3.forethought.net (mzpi5.forethought.net [216.241.36.14]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j9M5rUdu020341 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 Oct 2005 07:53:31 +0200 Received: from [216.241.35.41] (helo=[10.0.0.2]) by mz3.forethought.net with esmtp (Exim 4.51) id 1ETCJt-0006v9-48 for caml-list@inria.fr; Fri, 21 Oct 2005 23:53:29 -0600 Message-ID: <4359D3DC.5060307@gushee.net> Date: Fri, 21 Oct 2005 23:53:32 -0600 From: Matt Gushee User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Polymorphic class types? References: <4359534A.7080706@gushee.net> <1129945887.25457.216.camel@rosella> In-Reply-To: <1129945887.25457.216.camel@rosella> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4359D3DC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4359D3DA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 organising:01 model:01 model:01 conceptually:01 subtypes:01 rephrase:01 subtypes:01 ocaml:01 subtyping:01 subtyping:01 ocaml:01 programmer's:01 inference:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Thanks to John and Jacques for the thoughtful responses. skaller wrote: > I recommend you consider organising the 'cards' in a tree. > So you can iconify whole groups of them. Etc. I have a design > for that called Hierarchical Window Manager, allows you to > manipluate sets of things easily -- eg move a set of top > level window contents into a tabbed notebook (with a single > drag and drop operation). I've implemented it twice (once in > Itcl and once in Python). Interesting. I'm not sure a hierarchical model would apply here--the basic data model I'm trying to support is a graph rather than a tree. Think "visual RDF editor" ... though I'm not trying to tie this thing directly to RDF per se, it's conceptually pretty close. But I'd still be interested in how you did that. Is your Python code available somewhere? > You statement: > > "need to be various subtypes of cards, > each with appropriate display > logic for its content type" > > is wrong. on the contrary! The display manager MUST NOT > know anything about the content. All you really need is > a single 'render' method with a 'surface' argument, Maybe I didn't make myself clear. To rephrase myself more explicitly, "there need to be various subtypes of cards, each with appropriate display logic for its content type *embedded within itself*." Or if you understood that was what I meant, I don't see why you think it's wrong. Isn't this a textbook case of encapsulation? > BTW: the idea of using a 'polymorphic' class where the > data type is a type parameter is wrong (in Ocaml). > You need to use OO style subtyping here. I thought that's what I was doing. Not well, obviously, hence my inquiry to the list. If you have time, I'd like to hear more about this ... what exactly do you mean by OO style subtyping? I've heard "subtyping is not inheritance" about a thousand times ... but there's not much documentation on how to do it right in OCaml, and unfortunately I don't have enough theoretical background to figure it out on my own. Jacques Garrigue wrote: > The trouble with your approach (that I leave below) is that you do not > distinguish between the programmer's view of the card and the canvas > view of the card. Clearly the canvas does not need to know what is in > the card, just how to show it. Yes, actually I understood that. I didn't intend to create an ['a] canvas type, but since the canvas needed to know about cards and I had created the ['a] card type ... > class type card = object > [ .... ] > and another type > > class type ['a] data_card = object > inherit card Aha! Inheritance in class types ... I wasn't aware that you could do that (actually I think I may have done it once a couple of years ago, but if I did I must have forgotten about it). > Now you will say: but when I use get_card I won't be able to get to > the real card anymore. No, I won't say that ;-) Actually I think I was pretty close to that solution, just couldn't quite see it. > A smaller technical point: you are going to have to coerce your cards > to the type card. This can be done through (mycard :> card), but in > practice type inference is slow for that, and you don't want to see > the error message when it fails. Oh, yeah. I've seen quite a few of those error messages, and would be happy never to see another. > class virtual card = object (self) > ... > method as_card = (self :> card) Yes, I've done this before. Wow, I actually had the right idea about how to do something with OCaml objects? -- Matt Gushee Englewood, CO, USA