Browse thread
[Caml-list] does class polymorphism need to be so complicated?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Benjamin Geer <ben@s...> |
| Subject: | Re: [Caml-list] does class polymorphism need to be so complicated? |
brogoff@speakeasy.net wrote: > Yes, OCaml doesn't have implicit subtyping. [...] > 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;; I've thought some more about this idea of wrapper functions, and actually, it doesn't seem simple at all. In an object-oriented program, *all* methods are potentially polymorphic; this is what makes object orientation useful. It means that you can always pass, to a method in class C, an instance of a class that didn't exist yet when C was written. A library's author therefore doesn't need to anticipate all the classes that will ever use the library. If you used wrapper functions to do coercions, you would need a wrapper function for every method in the program. This would be extremely cumbersome and ugly, and hardly object-oriented. Doing coercions at the call site is equally cumbersome, and you lose the ability to change the method so that it accepts a less derived class. It seems to me that the idea of interfaces (class types) is quite powerful, and would be a good solution, if only the syntax for using them in method definitions were not so complicated. 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