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/

Awesome, 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?

> How are type classes in Haskell an OO feature?

See https://news.ycombinator.com/item?id=8280613

There are so many ways of doing OO.

Depends on how you define OO. My own definition of object involves identity and corresponding encapsulated state, which is something that Haskell doesn't support directly (since identity isn't pure).

Sure, but given your backgound, I imagine you are fully aware that back in the early 90's the OO community was quite divided about what are actually the core concepts and their implementation.

So, what OO is all about will depend which researcher gets asked.

Oh, fully agreed. I think my main point was that OO in a language such as OCaml has very little to do with OO in a language such as Scala (or Java). I'm agreeing with the OP that the marriage of OO and FP in Scala is problematic.

Yes, we can use less currently mainstream (note: not less correct) definitions of OO, but that doesn't help the Scala=OO+FP position.

Just like languages have versions/revisions, e.g: C++11,C++14, Java8 ...etc, having versions at major changes during evolution of OO might have helped in creating reference points which can facillitate discussions and enhance understanding i.e. like OO98, 0099, OO2005 ...etc.

That's impossible, because what would you write in OOxx, given the different CS views and programming models on the subject?

Jump dump what is being worked on at any given point in time?

For me it is hard to grasp how youngsters see OO or FP, because I was part of the initial mainstream waves. So I got to see the things in a different perspective.

The world at companies was procedural, and lots of experimentation was going on.

True. And in the end, this even applies to functional or declarative programming