Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Recovering masked methods
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-16 (12:45)
From: Alessandro Baretta <alex@b...>
Subject: Re: [Caml-list] Recovering masked methods (with CamlP4?)

Johan Baltié wrote:

> Uhh ? I have missed something. Can you forward me this post privately ? I cannot
> find it. It seems awful to me to hear that inheritance is "syntactic", because
> it does mean (for me) that nothing happen at runtime.

I've been looking for the exact post, but I can't find it. I 
remember distictly to have read something like that a little 
while ago, yet I cannot find the message.

Anyhow, insofar as I have understood the workings of the 
Ojbective part of the Caml, class inheritance is merely 
supposed to be a form of type safe code reuse (something of 
a macroexpansion to use C/++ terminology). In C++, if class 
B inherits from class A, B *is an* A. In O'Caml this is not 
true. B has all the functionality (read, "methods") provided 
by A. Nowhere is it guaranteed to be either type-equivalent 
to or a subtype of A. Therefore, an instance of B cannot be 
used wherever an instance of A can be used. And even if B 
*is a subtype* of A, then instances of B must be explicitly 
coerced to having type A (this amounts to method hiding, 
AFAIK) before they can be used as actual parameters to 
funtions whose formal parameter is of type A.

An example of this feature is Pxp's parse_document entity 
function. In order to check che validity of the use of ID 
and IDREF attribute fields in an XML document, the above 
function must be passed an object of type index = < 
{some_methods} >. But this is only a class type (an 
interface à la Java). Gerd Stolpmann provides an 
implementation class hash_index which is a sub_type of of 
index (implements the interface), but adds one extra method. 
In order to pass an object instance of hash_index to 
parse_document_entity you have to explicitly coerce it to 
having type index.

This is why it is perfectly sensible to let class 
variant_of_b inherit from class b, although the two classes 
*are not* in an "is a" relation with one another. You get 
the benefit of inheriting all the code in b which is also 
needed in variant_of_b, all the while retaining the 
possibility of adding methods to variant_of_b such that 
variant_of_b *is not a* b.

This approach to inheritance is radically different from 
that of C++. It takes a while to get the hang of it. It's 
actually much more powerful.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: