Re: [Caml-list] Polymorphic class types?

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

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