2 ms·
The fact that OO is not used frequently in OCaml does not mean that it is useless. Objects in OCaml are typed structurally, not nominally, i.e. object's type is
by a-nikolaev 12y ago
The fact that OO is not used frequently in OCaml does not mean that it is useless. Objects in OCaml are typed structurally, not nominally, i.e. object's type is the set of the methods it provides.
Consider an example:
let a = object method f x = 1 end;;
val a : < f : 'a -> int > = <obj>
We define an object a, and the interpreter tells us that the type of the object is "< f : 'a -> int >", i.e. it provides method f.
Define another object
let b = object method f x = 2; method g x = x end;;
val b : < f : 'a -> int; g : 'b -> 'b > = <obj>
Define a function that takes calls method f of its argument:
let f obj = obj#f ();;
val f : < f : unit -> 'a; .. > -> 'a = <fun>
The type of the function tells us that its argument must be an object that provides method f, and maybe some other methods. Now, we can call this function with object a, and object b:
f a;;
- : int = 1
f b;;
- : int = 2
This structural typing, (or if I'm not mistaken, it's called row polymorphism) is an interesiting feature of the language, and it may be useful in some situations. It does not harm the rest of the language, and I see it as a good feature that probably does not get a lot of attention, but it's theoretically solid and works well. Compared to more usual OO systems, it is cleaner and, imho, easier to reason about.
That said, I think, the authors of "Real World OCaml" are right, encouraging the use of Modules rather than Objects. But they do so primarily because in many mainstream languages the main means of abstractions are objects, and they are used for everything. OCaml has functors, modules, it has records, it has ADTs, it has functions, so the need for objects is very limited, and so the new users must get this message very clearly.
An article on objects in OCaml:
http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/
- the_af 12y agoAwesome, thanks for the explanation! I think I understand the appeal of structural typing: you are defining implicit anonymous interfaces as you write objects, and automatically grouping objects that share structure. But in which case is this more useful than, say, defining type classes or using explicit interfaces in mainstream OO languages? Or is it a case of preferences? I can see a difference with objects: in most mainstream OO languages you cannot retrofit an object to comply with the interface you want if you don't control the source code and the object only differs from what you need on a triviality such as naming. But what about type classes? Isn't this what they are there for?