From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id CBDB3BB9A for ; Sat, 22 Oct 2005 10:53:01 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j9M8r0PC011427 for ; Sat, 22 Oct 2005 10:53:01 +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 KAA12372 for ; Sat, 22 Oct 2005 10:53:00 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j9M8qwbZ006677 for ; Sat, 22 Oct 2005 10:52:59 +0200 Received: from rosella (ppp11-173.lns1.syd7.internode.on.net [59.167.11.173]) by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id j9M8qmXU018252; Sat, 22 Oct 2005 18:22:50 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Polymorphic class types? From: skaller To: Matt Gushee Cc: caml-list@inria.fr In-Reply-To: <4359D3DC.5060307@gushee.net> References: <4359534A.7080706@gushee.net> <1129945887.25457.216.camel@rosella> <4359D3DC.5060307@gushee.net> Content-Type: text/plain Date: Sat, 22 Oct 2005 18:52:48 +1000 Message-Id: <1129971168.4139.15.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4359FDEC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4359FDEA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 model:01 model:01 conceptually:01 vertically:01 widget:01 subtypes:01 recursion:01 subtyping:01 subtyping:01 ocaml:01 ocaml:01 subtype:01 ...:98 monitors: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 On Fri, 2005-10-21 at 23:53 -0600, Matt Gushee wrote: > 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? No sorry. The reason for a tree is that this is the model of containment. Notebooks contain windows .. vertically paned windows contain windows .. the Screen contains top level windows.. a network has many screens (I used to have two monitors, I could move things from one to the other with drag-n-drop). The containment relation uses a Tree widget instead of a linear 'toolbar'. Allows the user to group and regroup the 'card' content in interesting ways. > > 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. I think you did -- in any case Jacques Garrigue actually factored your model by removing the contents, I think what he did is correct. [oo subtypes] > I thought that's what I was doing. In some language of Barry Jay, you can actually do that: the parameter to a class is how you extend it, using open recursion. It's very nice -- if you instantiate the parameter to 'ground' the class becomes closed like with Java 'final'. > 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. In Ocaml a class D is a subtype of B if D has 'at least all the methods of B'. Inheritance may be convenient way to make this happen but it isn't essential. It's clear why this works: the interfaces are the same for B and D if you 'ignore some of the methods of D'. So any algorithm that works for a B will work for a D. [This isn't quite right as I'm sure someone will point out, but it is a good first approximation :] > > 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). It isn't inheritance.. its just a macro that pastes in the inherited signature (more or less :) Saves writing, nothing more. -- John Skaller Felix, successor to C++: http://felix.sf.net