Re: [Caml-list] Polymorphic class types?

[skaller <skaller@users.sourceforge.net>]

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 <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net