But how can I make MyModule to implement MySignature1 and MySignature2?
I know that in practice there might be signature fields conflicting between the two etc, but as long as I control the whole codebase, I can design it so the signatures are actually compatible or non-conflicting.
The workaround is to not define signature at all → after all things like functors are able to check the signature of a module even without it being explictly defined on the module. The difference between what I’m looking for, and that workaround, is the error message. I want my module to conform to (for example) two signatures like Order and Hash for various purposes, and if I modify signature I want the check to fail next to the module - not usage place.
module type A = {
type a
}
module type B = {
type b
}
module type AB = {
include A
include B
}
There is also extra syntax for dealing with collisions and abstractions, like include B with type a = or :=. There isn’t any rescript documentation on this, afaik, so I find it more useful to read the ocaml docs and translate. OCaml - The module system
I did this a lot when I first came from Haskell. After a handful of years, I sometimes will use include, but I don’t think I ever apply a module type at definition time (well, sometimes I do for debugging but then I delete it).
It isn’t wrong by any means, I just find that if you only limit modules in specific use cases (functors) instead of trying to track everything a module can do and immediately limiting it, you often end up with less code and a simpler design. That totally depends on the type of code you write though. I mostly write ddd style product services, so I have a specific set of goals.
When I really do want to limit the public interface of a module, I’m more likely to use a resi file, and leave the module type definitions for defining requirements for functors.