protocols, inheritance and polymorphism

[Dirk Thierbach]

Donn Cave <donn at drizzle.com> wrote:
> Quoth Jacek Generowicz <jacek.generowicz at cern.ch>:

> Given a model for polymorphism that means smuggling an object
> around wrapped in some degree of mystery about its type, elegant
> and sound static typing does seem unlikely.  But C++ and its
> descendents have always been easy targets.  Would you happen to
> know something about how Objective CAML's OO system approaches this?

In several ways: First, by using parametric polymorphism (not defined
as in this thread above, but by allowing "type variables" (type parameters)
which are applied as necessary, both in every expression, and in
object types. Second, by using so-called "row types", i.e. types
for incomplete records (in OCaml, they are denoted by the trailing dots
in a type like < get_x : int; set_x : int -> 'a; .. > ).

Together, they allow you to statically type most of the usual applications
of inheritance, virtual methods, etc. There used to be an somewhat
more contrived example in the OCaml manual with a subject/observer
pattern, virtual methods, and both abstract and concrete classes,
but I think they removed that some time ago.

As for

>> Specifically, dynamic polymorphism is impossible without dynamic
>> typing.

I haven't heard the term "dynamic typing" in this context, and I think
it's a bit unfortunate, because it's not "typing" in the usual
sense. If Jacek just means virtual methods, as in

>> In C++ you turn your classes into dynamically typed ones with the
>> "virtual" keyword, which introduces a vtable and run-time type
>> identification (RTTI).

that's easy to do in OCaml, and it also works in the type classes
of Haskell. The problem Jacek describes here:

>> As soon as you want to use a method present in the subclass but not
>> in the superclass, it is up to you to faff around with dynamic_cast
>> and checking of the resulting pointer;

is solved by keeping the parametric type "uninstantiated" as long
as possible, and instantiate it with the concrete type only when
it is clear that you really need the method present in the subclass.
Or, you handle this with the row types.

It does not work in every case one can think of right from the start
(you have to be able to statically guarantee that you have really the
subclass to work with at this point of your code, and not the
superclass), so you might to rewrite your code a bit to make it
work. Maybe it's easier to see if we do concrete examples.

> I see in the on-line documentation this paragraph:
> 
>   Be aware that subtyping and inheritance are not related. [...]

> I'm thinking that this might be more or less typical of academic
> ideas about OO typing, and it seems conceptually appealing.  I
> don't know the details though.

The "inheritance is not subtyping"-motto is somewhat orthogonal to
this issue. It comes originally from a paper by Benjamin Pierce, with
IIRC the same title. If you think this concept through, it really helps
to sort out some of the confusion that comes with the "usual" OOL's
like Java and C++.

- Dirk