]> Hello, Nobuyuki Tomizawa a écrit: > ------------------------------------------------------------ > class foo s = object > val str : string = s > method to_string ?(opt = "" ) () = opt ^ s > end;; > > let l = [new foo "a"; new foo "b"; new foo "c" ];; > > List.iter (fun e -> print_endline (e#to_string ())) l;; > > File "test.ml", line 8, characters 52-53: > This expression has type foo list but is here used with type > < to_string : unit -> string > list > Type foo = < to_string : ?opt:string -> unit -> string > > is not compatible with type < to_string : unit -> string > > ------------------------------------------------------------ This is quite normal: since the type of e is not constrained, ocaml has inferred the most general one from the body of the function: e must be an object with a method 'to_string' of type unit -> string . The problem comes from the fact that optional arguments and type inference do not work very well together (cf http://pauillac.inria.fr/ocaml/htmlman/manual006.html section 4.1.2). As suggested in the manual, the best solution might be to add a type annotation in the function above: List.iter (fun (e:foo) -> print_endline (e#to_string ())) l;; or List.iter (fun (e:#foo) -> print_endline (e#to_string ())) l;; if you intend to use subclasses of foo > > In contrast, I did not get the above message if I rewrote the program > into module style like: > module Bar : BAR = struct > type t = string > let create t = t > let to_string ?(opt = "") t = opt ^ t > end;; > > let m = [Bar.create "a"; Bar.create "b"; Bar.create "c" ];; > > List.iter (fun e -> print_endline (Bar.to_string e)) m;; Here, Bar.to_string has a perfectly defined type (namely ?opt:string -> Bar.t -> string), and optionnal arguments are treated inside the function. e itself is not involved in the process: it should only be of type Bar.t, and m is indeed a Bar.t list, so that everything works fine. In the object version, e is an object whose method to_string must have a certain type in which optionnal arguments are not necessarily taken into account. I'm afraid I'm not very clear here, but I'm not very familiar with labels, sorry... -- E tutto per oggi, a la prossima volta Virgile ------------------- 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