functors vs classes

functors vs classes

[Lyn A Headley]

hi,

In the caml programming language we are offered an (unprecedented)
choice between two varieties of modular polymorphism, classes and
functors.  Each offers distinct advantages, and yet in a way it seems
that each supports a different _style_ of programming.  In my limited
experience it seems that most people opt to focus on functors for
their modularization needs, and make little or no use of the objective
stuff.  How do others see this?

In my case I believe that both styles offer advantages, and that it
would behoove the prudent caml programmer to develop a style which
uses each paradigm, in the appropriate situation.  The question is,
how can we identify which situation deserves which representation?

Obviously inheritance is a main difference; object-oriented techniques
are appropriate for modeling trees of subclasses descended from a
common base.  And yet, so are variant types, as long as the tree
doesn't get too deep.  So it seems that if a type could have many
layers of inheritance, maybe an object would be the best
representation.  Otherwise, I'd take the conceptual simplicity,
readability and pattern matching that go along with variant types.

While both models offer polymorphism, the form taken is different.  It
seems that functors are appropriate when a finite number of program
units depend on or contain each other.  Objective polymorphism, on the
other hand, seems most effective (again) when programs contain various
instanciations of objects related hierarchichally.

I'm hoping to get some discussion on this issue since (a) I'd like a
clearer grasp of the material and (b) I imagine this is a common
question for new ocaml programmers, and I think it would be nice for
them if we could flesh out a document that describes the various
qualities and advantages of each paradigm.


Lyn

Re: functors vs classes

[Francois Rouaix]

> In the caml programming language we are offered an (unprecedented) 
> choice between two varieties of modular polymorphism, classes and 
> functors.  Each offers distinct advantages, and yet in a way it seems 
> that each supports a different _style_ of programming.  In my limited 
> experience it seems that most people opt to focus on functors for 
> their modularization needs, and make little or no use of the 
> objective stuff.  How do others see this? 

A historical note:
Objects are pretty much orthogonal to the rest of the system, and were
only very recently made available in Caml. Functors are a bit older, and
also much more familiar in the ML community.

AFAIK, I use both functors and objects. I find objects most useful when
manipulating a (possibly complex) state through a set of (possibly recursive)
functions. This situation arises very frequently in the kind of code I'm
writing : lots of IO and threads.

Also, I got the impression that functors and inheritance are much more
useful when designing and writing a library than when writing an application.


Mes deux centimes,
--f

OCaml's subtyping better than advertised?

[Donald Syme]

Dear Caml-ers,

Here's something I've noticed while reading the O'Caml manual.
It seems to me that the O'Caml manual undersells itself on 
one of the best features of the language: the separation of subtyping from
subclassing.  In particular I mean that one object type 
can be a subtype of another, without being related by the 
inheritance hierarchy.

In some recent OO books (e.g. "Large Scale Programming in C++") recurring
OO-related difficulties like the "rigid base class problem" have been pointed
out.  These frequently relate to the use of subclassing (implementation
inheritance) to achieve subtyping (sometimes called
interface inheritance, though this seems a little misleading as
interface inheritance is just one way of achieving subtyping).

It seems to me that one great advantage of the O'Caml
OO type system is that it frees the programmer to make use of 
implementation inheritance in just those few places where
it proves helpful.  (Indeed many would argue that implementation
inheritance is a bad thing per se, e.g. see the recent "language
wars" on comp.lang.<your-favourite-language>)

One thing I'm wondering is why the syntax for O'Caml types has no
way of specifying interface inheritance easily?  For
example, I want to define some object type (nb. I'm defining 
a type not a class):

  type widget = < windowid: unit -> int, 
                  set_height: int -> unit, 
                  height: unit -> int,
                  .. >;

[ Aside: at the moment I don't seem to be able to do this
  in O'Caml, without defining a class, because the type
  variable ".." is free.  Perhaps there needs to be come
  mechanism for defining new object types with the same
  "#<type>" behaviour of the types generated by classes?
  This would then allow me to write "#widget" as a type
  without having defined a class widget (i.e. without
  having committed to an implementation) ]

If I then want to define some structural subtype of #widget
(nb. not necessarily implemented by a subclass), I have to write out all
the methods again:

  type textual_widget = < windowid: unit -> int, 
                          set_height: int -> unit, 
                          height: unit -> int,
                          insert : string * int -> unit,
                          get : int * int -> string
                          .. >;


Also, the documentation says that a
type like "#point" (for some point class) unifies with any subclass of
point.  It seems worth emphasizing that such a type in fact unifies
with any object-type that has at least the methods from the class point,
whether or not the object-type is related by the interface hierarchy.

Speaking as someone who has done a fair bit of OO programming (in
C++ - bleah), I think this aspect of O'Caml's type system is fantastic.
The one other major thing that seems to be lacking (and no doubt hard to
implement efficiently) is some kind of runtime typechecking for coercions
down the subtype hierarchy.  [ The manual incorrectly
states that ":>" coerces to subtypes - in fact it coerces to
supertypes].  Whether or not such casts
are "necessary" could no doubt be a matter of vigorous debate
given the static-typing tradition of the ML languages, but
to me they seem unavoidable in some situations.  I guess you
can always use OCaml's "magic" and (as in C++) cross your fingers.

Yours,
Don Syme

P.S. Apologies for no french version.

Re: OCaml's subtyping better than advertised?

[Wolfgang Lux]

> One thing I'm wondering is why the syntax for O'Caml types has no
> way of specifying interface inheritance easily?  For
> example, I want to define some object type (nb. I'm defining 
> a type not a class):
> 
>   type widget = < windowid: unit -> int, 
>                   set_height: int -> unit, 
>                   height: unit -> int,
>                   .. >;
> 
> [ Aside: at the moment I don't seem to be able to do this
>   in O'Caml, without defining a class, because the type
>   variable ".." is free.  Perhaps there needs to be come
>   mechanism for defining new object types with the same
>   "#<type>" behaviour of the types generated by classes?
>   This would then allow me to write "#widget" as a type
>   without having defined a class widget (i.e. without
>   having committed to an implementation) ]
>

This *can* easily be done by using virtual methods, e.g.

virtual class widget () =
  virtual windowid: int (* unit -> ... is not necessary here! *)
  virtual set_height: int -> unit
  virtual height: int (* unit -> ... not necessary as well *)
end

> If I then want to define some structural subtype of #widget
> (nb. not necessarily implemented by a subclass), I have to write out all
> the methods again:
> 
>   type textual_widget = < windowid: unit -> int, 
>                           set_height: int -> unit, 
>                           height: unit -> int,
>                           insert : string * int -> unit,
>                           get : int * int -> string
>                           .. >;
> 

This is easily done as well:

virtual class textual_widget () =
  inherit widget ()
  virtual insert : string -> int -> unit
  virtual get : int -> int -> string
end

> 
> Yours,
> Don Syme

Regards
Wolfgang

> 
> P.S. Apologies for no french version.
Apologies from me as well.

----
Wolfgang Lux                     WZH Heidelberg, IBM Germany
Phone: +49-6221-59-4546                Fax: +49-6221-59-3500
Internet: lux@heidelbg.ibm.com          Office: mazvm01(lux)