3 ms·

> It partially helps since it forces you to have types where they matters most: exported functions But the problém the OP has is not knowing the types when rea

> It partially helps since it forces you to have types where they matters most: exported functions But the problém the OP has is not knowing the types when reading the source (in the .ml file). > How would it feels like to use list if only https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml was available, If the signature where in the source file (which you can do in OCaml too), there would be no problem - which is what all the other (for some definition of "other") languages except C and C++ (even Fortran) do. No, really, I can't see a single advantage of separate .mli files at all. The real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards - and now changes made later in the sources need to be documented in the mli too, so anything that doesn't change the type often gets lost. The same happens in C and C++ with header files.

yodsanklai 3y ago
How do you do encapsulation without an mli? can you hide the type implementation to the module user? can you ensure the exported functions (which are all of them without an mli) maintain your type invariant? > the real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards Of course, that would defeat the purpose of having interfaces and is incredibly bad practice. People do that when they try to fix an already broken codebase. It's actually pretty ironic that people who care about type safety (which I is why they use OCaml in the first place) don't value (or understand) things like encapsulation.
- ReleaseCandidat 3y ago
  > How do you do encapsulation without an mli? In OCaml you can't. If I could I wouldn't care about interface files, because I wouldn't need them.
- MrJohz 3y ago
  I find Rust is really effective in this regard. From my understanding of the capabilities of mli files, Rust's visibility modifiers are even more powerful in terms of effectively hiding implementation details and maintaining invariants, but they're all written inline in the source code (with the `pub` keyword). I agree that the encapsulation capabilities of mli files are great, but I don't see why they need to be written in a separate file (apart from the obvious reason: that's how OCaml does it, and you can't just change a language's design just because you don't like one bit of it!)

yodsanklai 3y ago

How do you do encapsulation without an mli? can you hide the type implementation to the module user? can you ensure the exported functions (which are all of them without an mli) maintain your type invariant? > the real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards Of course, that would defeat the purpose of having interfaces and is incredibly bad practice. People do that when they try to fix an already broken codebase. It's actually pretty ironic that people who care about type safety (which I is why they use OCaml in the first place) don't value (or understand) things like encapsulation.

ReleaseCandidat 3y ago
> How do you do encapsulation without an mli? In OCaml you can't. If I could I wouldn't care about interface files, because I wouldn't need them.
MrJohz 3y ago
I find Rust is really effective in this regard. From my understanding of the capabilities of mli files, Rust's visibility modifiers are even more powerful in terms of effectively hiding implementation details and maintaining invariants, but they're all written inline in the source code (with the `pub` keyword). I agree that the encapsulation capabilities of mli files are great, but I don't see why they need to be written in a separate file (apart from the obvious reason: that's how OCaml does it, and you can't just change a language's design just because you don't like one bit of it!)