I think the problem here might be that you are trying to replicate the annotation-style aspects directly using a different style. That won’t always be possible, or won’t always be elegant.

But there are problems to which there exist different solutions. As an example, I think the @Transactional annotation from JPA is a quite commonly applied cross-cutting concern.

How can we solve the problem of specifying, that some actions should be run in a transaction differently?

Slick has an interesting take on this: there, the database actions are reified as a data type. Any code that interacts with the database returns an object of type DBIOAction. Now, you can compose a number of such actions together sequentially. If you want to run them in a single transaction, simply call the .transactional method on the action object. This does not execute any actions against the database — it simply marks the actions that they should be run in a single transaction. It’s only a description; in other words, meta-data.

I think this approach has all the benefits of the annotation one, plus you get an extra degree of flexibility.

Scala software engineer, Functional Programming enthusiast, SoftwareMill co-founder

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store