Fuuzetsu
commented
6 years ago If you're going this way then go all the way: don't use type classes as the communication mechanism but records: https://www.schoolofhaskell.com/user/meiersi/the-service-pattern
Possibly we can pass these in explicitly at top level only and use type classes internally in each component for convenience (but see bottom of that link). This buys you a much easier way to inject stuff: mocks, logged versions of interfaces, caching layers &c. This pattern is useful in Real World™ code but it does have a buy-in cost.
I have started to think that the splitting of yi into separate packages might go easier if we make all packages indpendent of eachother and only allow them to communicate through very short and simple interface type classes. An example of my ideas is this pull request.
I think this way of programming allows the packages to be more easily changed. Right now there's a high change that you will cause one of the other packages to break if you make a change in yi-core. Only allowing each package to communicate via a small type class also makes the distinction between packages much more clear and force new code to be put in the right package.
What do you think? Is it too restrictive? Should typeclasses be used for this or should it just use records? I also haven't yet written a concrete implementation of
YiandYiMode, so maybe there are some mistakes in the type class definition.This will also allow us to stop with the lock-step versioning policy and version each package separately, but I don't know if that is a good idea.