I thank you all for the help... in the end, I solved the practical problem
by collapsing p and p2 into the same class -- not so nice, but it works, and
it is simpler than other solutions.

But the larger issue is: when a type is used for an input parameters, as the
type p in:
f : int -> p -> bool
why does the compiler have to complain that p has too many methods?
Would it not be possible to make the type checker smarter, and ensure that
when p is an input type, it is ok to have more methods?
And for output types as well, it would seem?
In other words, what is that fundamentally breaks if one were to change the
ocaml type checker in this way?

Luca

On 10/5/07, Edgar Friendly <thelema314@gmail.com> wrote:
>
> Luca de Alfaro wrote:
> > Yes, here is some code.  Any help would be very much appreciated.
> > The following fails to type check:
> >
> > class p (x: int) = object
> >   method plus1 : int = x + 1
> > end
> >
> > class p2 (x: int) = object
> >   inherit p x
> >   method plus2 : int = x + 2
> > end
> >
> > class r = object (self)
> >   val mutable l = []
> >   method make_el x = new p x
> >   method add (x: int) : unit = l <- (self#make_el x) :: l
> >   method length : int = List.length l
> >   method total : int = List.fold_left (fun t el -> t + el#plus1) 0 l
> > end
> >
> > class r2 = object
> >   inherit r
> >   method make_el x = new p2 x
> >   method total2 : int = List.fold_left (fun t el -> t + el#plus2) 0 l
> > end
> >
> if I manually perform the inherit operation by pasting the code from r1
> into r2, I get:
>
> class r2 = object (self)
>   val mutable l = []
>   method make_el x = new p2 x
>   method add (x: int) : unit = l <- (self#make_el x) :: l
>   method length : int = List.length l
>   method total2 : int = List.fold_left (fun t el -> t + el#plus2) 0 l
> end
>
> which compiles just fine, and probably works as intended.  If I include
> the original method make_el above the new one like this:
>   method make_el x = new p x
>   method make_el x = new p2 x
> Ignoring the warning about overriding methods within the same class, we
> come to the root of the type problem: make_el must have a type.  After
> inference completes on the first line, make_el's type is determined to
> be p.  The second make_el's type must match, but it doesn't.  I don't
> see a solution for your problem that doesn't involve this kind of manual
> expansion and removal of duplicate methods, but I'm fairly sure this is
> the real problem for you.
>
> E.
>