# Objects use cases in OCaml
**URL:** https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282
**Category:** Learning
**Tags:** oop, objects
**Created:** [July 12, 2018, 9:27am UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282 "2018-07-12T09:27:40Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@egoholic](https://discuss.ocaml.org/u/egoholic)
#### Post date: [July 12, 2018, 9:27am UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/1 "2018-07-12T09:27:40Z")
Typical OCaml developer prefers not to use OO-features, but sometimes choosing objects over other composable “granules” is the simplest solution. Could you please share your own experience when objects is a MUST or a best practice in OCaml programs.
---
### Author:  [@Drup](https://discuss.ocaml.org/u/Drup)
#### Post date: [July 12, 2018, 9:42am UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/2 "2018-07-12T09:42:54Z")
I have seen on regular occasions fairly advanced OCaml programmers write something like this:
```ocaml
module type S = sig
type t
val do_thing : t -> t -> t
val to_string : t -> string
val other_function : ....
end
type 'a state = ('a * (module S with type t = 'a))
```
If you are tempted to use that pattern on a large scale at some point in your ocaml programming life, just use objects. 🙂
---
### Author:  [@Yaron\_Minsky](https://discuss.ocaml.org/u/Yaron_Minsky)
#### Post date: [July 12, 2018, 10:04am UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/3 "2018-07-12T10:04:35Z")
I’d give the opposite advice. I basically never use objects, and I think first class modules rightly absorb most of the use-cases that would otherwise lead one towards objects, and that seems preferable to me.
All in, I’d prefer if OCaml didn’t have an object subsystem, though really swallowing all of the uses of objects would require some more sophistication at the module-system level.
y
---
### Author:  [@jonathandoyle](https://discuss.ocaml.org/u/jonathandoyle)
#### Post date: [July 12, 2018, 1:27pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/4 "2018-07-12T13:27:18Z")
That reminds me of that quote by Joe Armstrong on IBM and OO programming :
> [@Joe Armstrong](#):
>
> After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like “swearing in church”. OOness became something that every respectable language just had to have.
>
> As Erlang became popular we were often asked “Is Erlang OO” - well, of course the true answer was “No of course not” - but we didn’t to say this out loud - so we invented a series of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully).
>
> At this point I am reminded of the keynote speech of the then boss of IBM in France who addressed the audience at the 7th IEEE Logic programming conference in Paris. IBM prolog had added a lot of OO extensions, when asked why he replied: “Our customers wanted OO prolog so we made OO prolog” I remember thinking “how simple, no qualms of conscience, no soul-searching, no asking "Is this the right thing to do” …
Isn’t it the same that happened with the “O” in OCaml ?
---
### Author:  [@schrodibear](https://discuss.ocaml.org/u/schrodibear)
#### Post date: [July 12, 2018, 1:53pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/5 "2018-07-12T13:53:19Z")
Two fairly common use cases that I encountered:
- bindings to object-oriented libraries e.g. Gtk and various JavaScript libraries
- visitors/traversers, here even Jane Street’s [ppx\_traverse](https://github.com/ocaml-ppx/ppxlib#traverse-and-traverse_builtins) uses objects
---
### Author:  [@Yaron\_Minsky](https://discuss.ocaml.org/u/Yaron_Minsky)
#### Post date: [July 12, 2018, 2:44pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/6 "2018-07-12T14:44:53Z")
Amusingly, ppx\_traverse is close to the only spontaneous use of OCaml objects in our libraries. @Jeremie Dimino could probably explain more about why objects are the right choice here, because it’s not obvious to me.
y
---
### Author:  [@bluddy](https://discuss.ocaml.org/u/bluddy)
#### Post date: [July 12, 2018, 3:01pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/7 "2018-07-12T15:01:19Z")
Open recursion? If you want to extend and modify the behavior of an existing piece of code with a minimum of fuss, objects are a good choice.
---
### Author:  [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)
#### Post date: [July 12, 2018, 3:03pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/8 "2018-07-12T15:03:09Z")
@Yaron_Minsky When we initially wrote this code, we started with records. However the code looked like manual inheritance and it was very easy to call the wrong callback. With objects the code was much clearer.
---
### Author:  [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)
#### Post date: [July 12, 2018, 3:04pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/9 "2018-07-12T15:04:57Z")
Additionally the syntax for record of functions is a bit ugly compared to the syntax of objects.
---
### Author:  [@schrodibear](https://discuss.ocaml.org/u/schrodibear)
#### Post date: [July 12, 2018, 3:12pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/10 "2018-07-12T15:12:40Z")
One other argument can be that if there’s a need to pass a visitor handling a superset of node types as an argument to function that only need to apply it to a subset of the types, there’s no need in a coercion. First-class modules need a re-packing in those cases, records need re-allocation. But of course with objects there’s than a cost of method lookup and no method inlining…
```ocaml
module type S = sig val x : int end;;
module type S' = sig val x : int y : int end;;
let f (module M : S) = ();;
module M : S' = struct let x = 5 let y = 6 end;;
let m = (module M : S');;
f m;;
(*Error: This expression has type (module S')
but an expression was expected of type (module S)*)
f (m :> (module S));;
(* Error: Type (module S') is not a subtype of (module S) *)
f (let (module M) = m in (module M));; (* OK *)
```
---
### Author:  [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)
#### Post date: [July 12, 2018, 3:23pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/11 "2018-07-12T15:23:10Z")
BTW, for performances, we found that a lot of the cost of ppx rewriters came from the fact they were applied as separate whole passes. Merging them all into one pass divided the time spent in preprocessing quite a bit. We have a blog post about it: [https://blog.janestreet.com/ppx\_core-context-free-rewriters-for-better-semantic-and-faster-compilation/](https://blog.janestreet.com/ppx_core-context-free-rewriters-for-better-semantic-and-faster-compilation/)
---
### Author:  [@Thierry\_Martinez](https://discuss.ocaml.org/u/Thierry_Martinez)
#### Post date: [July 12, 2018, 10:29pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/12 "2018-07-12T22:29:51Z")
The package `visitors`, of François Pottier, makes wide usage of objects. [https://gitlab.inria.fr/fpottier/visitors](https://gitlab.inria.fr/fpottier/visitors)
---
### Author:  [@mmottl](https://discuss.ocaml.org/u/mmottl)
#### Post date: [July 15, 2018, 7:11pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/13 "2018-07-15T19:11:22Z")
When OCaml first introduced its object system, it was, at least in my memory, at around the peak of the popularity of OO as a language design feature (mid to late 90s). OO was considered the holy grail that would solve all issues of reusability. That’s what we basically got shoved down our throats in freshman classes.
But when I actually tried to implement more complex OO applications, something never felt right to me. I started reading books on language design and downloaded OCaml as well as other “academic” languages. The fact that it also supported OO gave me confidence that I would be able to use my OO skills while learning about functional programming. Needless to say, it took only a few months before I came to the conclusion that using algebraic datatypes, first class functions, and modules was a much better way to design applications.
I tried once in a while to use objects when it seemed convenient. In all cases I eventually regretted this choice. As far as OO type systems go, OCaml is much better designed than just about any alternative. Nevertheless, I still wouldn’t waste a tear if the OO part were removed. That said, it helped get me interested in OCaml back in the days.
---
### Author:  [@jonathandoyle](https://discuss.ocaml.org/u/jonathandoyle)
#### Post date: [July 16, 2018, 12:06pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/14 "2018-07-16T12:06:11Z")
> [@Drup](#):
>
> I have seen on regular occasions fairly advanced OCaml programmers write something like this:
>
> ```ocaml
> module type S = sig
> type t
> val do_thing : t -> t -> t
> val to_string : t -> string
> val other_function : ....
> end
>
> type 'a state = ('a * (module S with type t = 'a))
>
> ```
>
> If you are tempted to use that pattern on a large scale at some point in your ocaml programming life, just use objects. 🙂
As a side note, I only use the `to_string` name when there is only one, obvious way to convert `t` to a string. When there are several functions that might be called “to\_string”, I prefer to call none of them “to\_string” and force myself to find more descriptive names for each.
The OO philosophy of “reusing as much as possible” the `to_string` method name actually makes users spend more time browsing the manual to see what “to\_string” really does, IMHO.
---
### Author:  [@jhw](https://discuss.ocaml.org/u/jhw)
#### Post date: [July 16, 2018, 4:01pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/15 "2018-07-16T16:01:24Z")
I’ve had some success using class types in the constraint expressions for shadow type parameters in abstract types representing objects of foreign language types where class inheritance is a thing.
---
### Author:  [@RogerT](https://discuss.ocaml.org/u/RogerT)
#### Post date: [November 12, 2018, 12:46pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/16 "2018-11-12T12:46:47Z")
Is the following recommendation from [ocaml.org](http://ocaml.org) still valid and complete?
[https://ocaml.org/learn/tutorials/guidelines.html#How-to-choose-between-classes-and-modules](https://ocaml.org/learn/tutorials/guidelines.html#How-to-choose-between-classes-and-modules)
(if it is not, it would be a great chance to update it, because [ocaml.org](http://ocaml.org) is a main entry point for new comers where there is very good stuff as well as ambiguous or too old information).
> **How to choose between classes and modules**
> You should use OCaml classes when you need inheritance, that is, incremental refinement of data and their functionality.
>
> You should use conventional data structures (in particular, variant types) when you need pattern-matching.
>
> You should use modules when the data structures are fixed and their functionality is equally fixed or it’s enough to add new functions in the programs which use them.
@mmottl (and to others who feel concerned): Can you describe your experience about turning from OOP to FP? Can you explicitly tell us what you should really change in your mindset and toolset?
Today, if you have a look at a “(unusually) well designed” UML model (especially constrained with clear OCL), can you see any limitations of OCaml to implement it? Or does it appear always clear that OCaml modules will do the job ?
We could distinguish two different contexts:
Case 1: the model is quite definitive and only satellites classes will be added, or global implementation will continuously be improved (new libs…).
Case 2 (more usual): it is already known that the core model will evolve, progressively but rather drastically (think about the case of a merging between two companies).
---
### Author:  [@etc](https://discuss.ocaml.org/u/etc)
#### Post date: [November 12, 2018, 8:05pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/17 "2018-11-12T20:05:47Z")
It’s worth mentioning that objects are useful for modeling existing object-oriented API’s. I think bucklescript and js\_of\_ocaml both use them to model the DOM api. [Lablgtk](http://lablgtk.forge.ocamlcore.org/) also exposes the Gtk api directly in OCaml, and I think was part of the incentive for researching and adding objects to OCaml.
I also really like the structural polymorphism that it adds: being able to write a function that doesn’t care the type of a particular piece of data, so long as it exposes a certain set of methods. The cool part is that nowhere do you have to specify the set of methods: OCaml can infer it. I worked on a small project that plays with this a bit called [Orb](https://github.com/charlesetc/orb)
---
### Author:  [@mmottl](https://discuss.ocaml.org/u/mmottl)
#### Post date: [November 12, 2018, 8:42pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/18 "2018-11-12T20:42:45Z")
My main initial reason for switching away from OOP was the observation that algebraic datatypes + pattern matching proved to be greatly superior in clarity and conciseness. Later I realized that the module system was better at expressing relations between different types and allowed for stronger abstraction guarantees. Overall, FP code was simply much easier to reason about.
As for changing your mindset, convince yourself by implementing some frequently used data structures (i.e. the nitty-gritty details) with either objects or algebraic datatypes. Then practice big-picture programming by e.g. refactoring code either using the object system or the module system (functors). With some practical experience most people realize soon that OOP rarely if ever delivers better results.
I never look at UML models. Back in my days as a student, CASE (Computer Aided Software Engineering) was all the rage so all kinds of graphical formalisms (including UML) were pushed on us, invented to delude business managers that all it takes to develop great software is to make some beautiful drawings that the computer would then magically implement. Finally they could get rid of all those overcompensated computer nerds! When this didn’t quite work, they forced cheap imported programmers to robotically implement them, with predictable outcomes for delivering quality products in a timely manner. Eventually, CASE fell out of vogue.
AFAIK, today UML is mostly used sloppily and pretty much exclusively within the OO community to facilitate the communication of design ideas. Nothing wrong with that. But more “rigorous” UML doesn’t seem to add much value. I’m not aware of graphical formalisms having any traction in the FP community. Academic research associated with FP is heavily invested in formal methods (type systems, automated theorem proving) to automatically implement (or at least help implement) provably correct software. The advanced static type systems modern FP languages like OCaml offer are essentially an intermediate step towards that goal.
---
### Author:  [@perry](https://discuss.ocaml.org/u/perry)
#### Post date: [November 12, 2018, 10:17pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/19 "2018-11-12T22:17:14Z")
I note that even in languages like C++, inheritance is not nearly so used as it was when the language was conceived. Instead, polymorphism is usually achieved with the template system.
---
### Author:  [@ivg](https://discuss.ocaml.org/u/ivg)
#### Post date: [November 13, 2018, 3:03pm UTC](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/20 "2018-11-13T15:03:09Z")
Classes provide open recursion with late binding with a row polymorphic self type. In a separate, all these facilities are provided by other language mechanisms that are more straightforward and easier to use and understand. So following Occam’s razor principle it is better to use the least heavy tool. Let me expand this definition before going any further.
1. open recursion - is a technique when a recursive function calls itself not directly, but via an explicit parameter, e.g.,
```ocaml
let fact self n = if n = 0 then 1 else n * self (n - 1)
```
The fixpoint combinator could be used to tight things up, e.g.,
```ocaml
let rec fix f n = f (fix f) n
let fact n = fix fact n
```
So, as you can see, there is no need to use classes for open recursion as you can use explicit functions or records for that (as done in the OCaml’s AST rewriters).
1. Late binding is a technique when a function is not called directly, but via a slot that could be overridden in runtime by any other function with a matching type. Technically, this means that the `self` parameter is mutable. That allows an algorithm to call a method that is dispatched based on some runtime information. Beside the obvious solution with mutable records, it is possible to use recursive modules, e.g.,
```ocaml
type student = {age : int}
module type Student = sig
type t
val create : int -> t
val age : t -> int
val say : t -> string
end with type t := student
module Base(S : Student) : Student = struct
let create age = {age}
let age s = s.age
let say t = "I'm " ^ string_of_int (S.age t) ^ " years old\n"
end
module Older(S : Student) : Student = struct
include S
let age s = S.age s + 1
end
module Younger(S : Student) : Student = struct
include S
let age s = S.age s / 2
end
module Same : Student = Older(Init)
module rec S1 : Student = Base(Younger(S1))
let s1 = S1.(say@@create 20);;
module rec S2 : Student = Base(Younger(S2))
let s2 = S2.(say@@create 20);;
```
As you can see we can override methods, and even explicitly specify the the order of inheritance. Underneath the hood the compiler allocates a function table for each operation in the interface and assigns each operation an implementation in the order of the functor applications. This is basically what happens with classes, so we nearly got OO with functors, however, we still have some limitations wrt to what classes can give us.
1. polymporhic self type - as we can see from the previous example, we had to constrain the student type to some concrete implementation. But what if we need to keep it polymorphic and enable refinement (i.e., adding new operations or deleting constructors) of the self type in the derived classes? Thanks to the addition of [private row types](http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec240), we can actually do this with recursive modules, (depending on what we want we can use polymorphic variants or object types to denote row types). The object type example is provided in the OCaml manual, an example with a polymorphic variant is provided below:
```ocaml
module type Ops = sig
type expr
val eval : expr -> expr
val show : expr -> string
end
type 'a expr0 = [`Num of int | `Plus of 'a * 'a]
module F(X : Ops with type expr = private [> 'a expr0] as 'a) = struct
let () = print_string "eval F"
type expr = X.expr expr0
let eval = function
| `Num _ as x -> x
| `Plus (x,y) -> match X.eval x, X.eval y with
| `Num m, `Num n -> `Num (m+n)
| z -> `Plus z
let show = function
| `Num x -> string_of_int x
| `Plus (x,y) -> "(" ^ X.show x ^ " + " ^ X.show y ^ ")"
end
module rec L : (Ops with type expr = L.expr expr0) = F(L)
```
So, using functors together with private row types we can implement arbitrary class architectures. However, at some point of time, using classes directly will become a cleaner and even more robust solution. For example, the classes infrastructure in OCaml comes with some prebuilt mechanisms, like virtual methods whose implementation is checked at compile time (recursive functors will fail in runtime if any method is not implemented).
So once your domain actually requires you to model complex and open recursive types, so that you need to use modularity to split the definitions of recursive algorithms for those types into different modules, and you have to keep the type polymorphic and open to extension (i.e., the hierarchy is not closed). Then you may choose classes for that.
In the real world such hierarchies are very rare and such design constraints are even rarer. A particular example is a complex and extensible recursive language, i.e., when you have to write an analysis for the language that is extensible (i.e., when the set of branches in AST is not closed). A particular example, would be `camlp4` and `camlp5` which are frameworks for writing extensible pretty printers and parsers.
However, when not only the language is extensible but the set of analysis (i.e., the set of operations applied to the language) is also meant to be extensible, then you hit the so called [Expression Problem](https://en.wikipedia.org/wiki/Expression_problem). In that case neither algebraic data types, nor class hierarchies will work and you have to switch to Object Algebras aka [Tagless Final](http://okmij.org/ftp/tagless-final/JFP.pdf) approach.
[Next page](https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282.md?page=2)