Oleg wrote:
> 
> > And how would you do more complex case analysis, corresponding to nested
> > patterns?
> 
> I think I know what nested patterns are (something like
> Node (x, y, Bla(1, _)) -> ...), but I don't see where any extra difficulty
> will come from while using virtual functions. Could you give specific
> examples please?

Consider a simple expression language again. This time extended with
variables and function expressions:

  type 'a expr = Const of 'a | Var of string
               | Unop of 'a -> 'a
               | Binop of 'a -> 'a -> 'a
               | Lambda of string * 'a expr
               | Apply of 'a expr * 'a expr

Evaluation has to rely on (one-step) reduction (sketch only):

 let rec reduce1 env = function
 | Var x -> List.assoc x env
 | Apply (Lambda (x, e), v) -> eval ((x,v)::env) e
 | Apply (Unop f,  Const x) -> Const (f x)
 | Apply (Binop f, Const x) -> Unop (f x)
 | Apply  _ -> raise Error
 | e -> e

Doing this with method dispatch requires serious amounts of object
spaghetti. I believe you are imaginative enough to see that this is
absolutely hopeless for realistic examples with a large number of more
complex cases - the number of additional helper methods polluting all
your classes will grow exponentially. (And note that even multiple
dispatch isn't expressive enough to avoid that.)

> > This is more than cumbersome and error-prone in C++ - with
> > RTTI, and even more so with method dispatch, where your single algorithm
> > will have to be scattered over tons of distant functions. A maintenance
> > nightmare.
> 
> Why would maintaining code organized by data type be harder? Isn't it what
> encapsulation is all about?

No. That's one of the things OO ideology gets wrong. Making the type the
unit of encapsulation is much too inflexible. Often you want to
encapsulate several types simultanously, e.g. when you have functions
operating on a group of closely related types, which cannot sensibly be
implemented knowing only one of the types' internals. Thus
orthogonalising types and modules is a definite plus.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
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