2 ms·
> Having a terse little file where I can scan the interface of a module, rather than having to scroll through the implementation and see which declarations have
by MaxBarraclough 5y ago
> Having a terse little file where I can scan the interface of a module, rather than having to scroll through the implementation and see which declarations have `public` in front of them, is a great way to quickly refresh your mental model of a module's API.
There's also another structured approach to the interface/implementation distinction: leave it up to the IDE to offer an interface explorer. This is the approach used by, say, Java.
I'm not sure that either approach is outright better than the other; it's a trade-off.
- zetalyrae 5y agoI tend to prefer things being on the code itself as opposed to being added dynamically by the IDE. For example I think type annotations should be in the IDE. This is because it lets me read code in extra-IDE settings: browing GitHub, or in a patch file, or on a book. Or I can write code on paper. Another benefit is that you can design a program entirely by writing the module interface files, and typechecking them against each other without an actual module body file. Then, as you start actually implementing the program, you can implement one module at a time, typechecking it against the module interfaces of its dependencies, without said dependencies having any actual code in them. So you can write the actual implementation in whatever order makes sense.