Re: [Caml-list] Ocaml and the Fragile Base Class Problem

[Alain Frisch <alain@frisch.fr>]

On 8/29/2011 5:35 AM, Jacques Garrigue wrote:
> If you want just to structure your program, modules are better in most cases.
> There are still situations where classes are stronger than modules for structuring:
> * when you have a default for some operation, but want to be able to change it
> * when you want to mix components, using multiple inheritance and virtual methods
>    and instance variables

I second that.  We are moving some parts of our code base to a mixin 
style implemented with multiple inheritance, virtual methods, 
constraints, very rare overridding (and no instance variables).  This 
results in drastic reduction of code size compared to our previous 
approach where code sharing between components was implemented with 
simple function calls.   The code is also easier to evolve.

We create objects (without state) to represent bags of properties 
computed from parameters; each method represents a property. An object 
is created by assembling reusable mixins (inheritance) and implementing 
remaining virtual methods.  Once the object is created, we observe a few 
properties and throw the object away.  In effect, we use objects to 
describe purely functional computation graphs, with reusable sub-graphs. 
  (Most methods don't take argument; in order to avoid repeated 
evaluation, we have a special hack which rewrites an object's method 
table so as to give its methods a lazy behavior.)

The nice thing with this approach is that the object layer does all the 
plumbing automatically. Combining several reusable components does not 
require to pass data around from one component to another explicitly. 
The old style with functions required to pass many arguments, 
deconstruct the result (a component typically computes several things), 
organize reusable components to avoid mutual recursions, and define many 
data types (records to represent the result of components).  In some 
cases, a large amount of the code was caused by such plumbing.


> Also, for various reasons, objects are not beginner friendly.
> I think the main problem is that they don't fit that well with type inference:
> both subtyping and polymorphic methods require explicit type annotations.

Time to advertise the implicit-subtyping branch?


-- Alain