Re: [Caml-list] Recovering masked methods

[John Prevost <j.prevost@cs.cmu.edu>]

>>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:

    ab> This is not viable. The toy code I have shown here does not
    ab> provide any real functionality, but in the real application
    ab> you have to imagine the following situation:

class a =
object (self)
   method m = <some generally useful stuff
   method m1 = <other generally useful stuff>
   ...
   method mn = <other generally useful stuff>
end

class b =
object (self)
   inherit a as super_a
   method m = <specific stuff>; super_a # m
   method m1 = <specific stuff>; super_a # m1
   ...
   method mn = <specific stuff>; super_a # mn
end


class small_variant_of_b =
object (self)
   inherit b as super_b
   method m = super_b # super_a # m
(* All the specific stuff in method m is not needed *)
(* Yet, all other methods must be inherited from b  *)
end

    ab> Without the above notation, I could only think of copying the
    ab> code of method m out of class a and pasting it into class
    ab> small_variant_of_b, but this makes maintainance a mess. And I
    ab> am working on a production class system. No good. However, I
    ab> did not consider the following idea, which is not bad
    ab> indeed. In the absence of the notation I described above, or
    ab> of an equivalent one, I'll do as you propose here.

Just as a note, I would argue that doing the above is an indication
that you're over-using class inheritance.  If you need access to the
method "m" in both "a" and "b", then it's not really the same method.
If you need access to only one or the other (in this case, only the
one in a), how about:

class a =
  object
    method m = ...
    method m1 = ...
    ...
    method mn = ...
  end

class b' =
  object
    inherit a as s
    method m1 = ...; s #m
    ...
    method mn = ...; s #mn
  end

class b =
  object
    inherit b' as s
    method m = ...; s #m
  end

class var_b =
  object
    inherit b' as s
    method m = ...; s #m
  end

Remember that unlike most class-based languages, object *typing* in
O'Caml is orthogonal to inheritance.  Even though var_b does not
inherit from b, as long as method m has the same type signature,
they're compatible.  Since this is true, you should subclass purely to
share functionality--and in this case, you have two classes that share
functionality: b and the variant of b.  In fact, they share code for
everything except method m.

Isn't this a perfect example of when you *do* want to use inheritance
for code sharing?


Note that this is actually one place where the proper use of
inheritance is different from that in most OO contexts.  In most OO
languages, you should only subclass when you want to subtype.  That
is, subclasses of a given class should exist because each subclass is
a kind of the thing defined by the superclass.  Much OO literature
recommends *against* subclassing simply for purposes of sharing code,
because it complicates the control flow and can lead to subtle errors.

In O'Caml, you need not subclass to get subtyping.  In fact,
subclassing does not necessarily produce a subtype.  So by contrast,
in O'Caml the only time you ever should subclass is if you intend to
re-use code.  It's still true that this can complicate the control flow
and lead to subtle errors--but since subtyping is separate, there's no
need to subclass at all unless you're re-using code.

A very good example of this is an example that used to exist in the
O'Caml manual (I think) of linked lists and doubly linked lists.  In
O'Caml, it's reasonable to define doubly linked lists as inheriting
from linked lists in order to share code.  However: doubly linked
lists are not type-compatible with linked lists, so they're not a
subtype.

So: inherit in moderation.


John.
-------------------
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