Re: [Caml-list] Polymorphic class types?

[Matt Gushee <matt@gushee.net>]

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