Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] does class polymorphism need to be so complicated?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: brogoff@s...
Subject: Re: [Caml-list] does class polymorphism need to be so complicated?
On Wed, 20 Aug 2003, Benjamin Geer wrote:
> Unless I've missed something, this only works if none of the classes of 
> type fbbq have any additional methods.  Here's an example that doesn't work:

Yes, OCaml doesn't have implicit subtyping. The language manual is quite clear 
on that. If you want to solve your problem, you'll need to coerce, and you 
can solve it fairly simply by replacing the troublesome line below with one of 
the following 

tp#process (et :> fbbq) ;;

or 

let proc o = (new thing_processor)#process (o :> fbbq);;
proc et;;

or stuff like that. You get the picture. The (row) type representing 
"fbbq or anything which has the same methods" is this 

type 'a fbbq_c = 'a constraint 'a = 
    < foo: int->int;
      bar: unit->string;
      baz: unit->bool;
      quux: unit->unit; .. >

where as you can see there is a type variable to handle that row polymorphism. 
So, if you want a method which takes that as an argument, it has to be 
polymorphic. Easier to solve it as I did above with a function wrappers and 
coercions. A solution using polymorphic methods is sketched next, where I 
use them to fake implicit subtyping

class type thing =
    object
      method foo : int -> int
      method bar : string
      method baz : bool
      method quux : unit
  end;;

class thing_processor =
   object
     method process : 'a . (#thing as 'a ) -> unit =
       fun obj ->
         begin
           obj#quux;
           print_string (string_of_int (obj#foo 1));
           print_string obj#bar;
           print_string (string_of_bool obj#baz);
           print_endline ""
         end
   end ;;
let tp = new thing_processor ;;
tp#process et ;;

so I guess you are now left with a Perl like TMTOWTDI situation. 

Overall, yes, the class system is complicated. 

-- Brian

> type fbbq =
>    <foo: int->int; bar: string; baz: bool; quux: unit > ;;
> 
> class thing x_init =
>     object (self)
>       val mutable x = x_init
>       method foo y = x + y
>       method bar = string_of_int (self#foo 2)
>       method baz = (x = 1)
>       method quux = print_string (string_of_int x)
>   end;;
> 
> class extra_thing x_init =
>     object (self)
>       inherit thing x_init
>       method quuux = self#quux; self#quux
>   end;;
> 
> class thing_processor =
>    object
>        method process (obj : fbbq) =
> 	obj#quux;
> 	print_string (string_of_int (obj#foo 1));
> 	print_string obj#bar;
> 	print_string (string_of_bool obj#baz)
>    end ;;
> 
> let et = new extra_thing 1 ;;
> let tp = new thing_processor ;;
> tp#process et ;;
> 
> The call to 'process' produces the following error:
> 
> This expression has type
>    extra_thing =
>      < bar : string; baz : bool; foo : int -> int; quuux : unit; quux : 
> unit >
> but is here used with type
>    fbbq = < bar : string; baz : bool; foo : int -> int; quux : unit >
> Only the first object type has a method quuux
> 
> So this approach doesn't fit the requirement, which is to be able to use
> a derived class anywhere its base class can be used.
> 
> Ben
> 
> -------------------
> 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
> 


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