[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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.
Alex
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners