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 AD27EBB9A for ; Sat, 22 Oct 2005 03:51:39 +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 j9M1pccn029771 for ; Sat, 22 Oct 2005 03:51:39 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA05422 for ; Sat, 22 Oct 2005 03:51:38 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j9M1paFA006997 for ; Sat, 22 Oct 2005 03:51:37 +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 j9M1pRIJ055661; Sat, 22 Oct 2005 11:21:28 +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: <4359534A.7080706@gushee.net> References: <4359534A.7080706@gushee.net> Content-Type: text/plain Date: Sat, 22 Oct 2005 11:51:26 +1000 Message-Id: <1129945887.25457.216.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43599B2A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 43599B28.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 abstraction:01 abstractions:01 minimise:01 organising:01 subtypes:01 ocaml:01 subtyping:01 generalise:01 positioning:98 wrote:01 sourceforge:01 polymorphic:01 polymorphic:01 arbitrary:01 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 14:44 -0600, Matt Gushee wrote: > So you are probably starting to get a sense of the problem: I need a > basic framework of display logic that is independent of the application > data, for positioning cards on the canvas, handling events, etc. But I > also need to be able to get and set the content of cards in response to > GUI events--the content being some arbitrary data structure, as > mentioned above. Basic abstraction. The cards are abstractions, they have no content. Make that work first for placement, iconisation, etc. Display the content as 'whiteness' or something. Derive a new class which has content. The algorithms for display management will not know about it. That is right. The best way to derive a new class is to make one which just delegates to another object, to allow you to move content around easily, and also avoid confusion about what parts of the object type really do need to be coupled with the subclass (and try to minimise that). 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). 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, so the display manager can tell the underlying object when to render itself and where. [ok, you may need size and 'skin' and a couple of other things too] 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. The reason is -- you cannot generalise your display manager to work over a heterogenous collection which is what you would get with many distinct instances of the polymorphic class. -- John Skaller Felix, successor to C++: http://felix.sf.net