Most OO programming techniques aim to help break a program into smaller units around well-defined functional areas. But some functional areas defy such encapsulation and abstraction.
Logging and transaction management are two oft-quoted concerns that cross-cut many components in a real-world enterprise system: Because many classes can potentially rely on logging and transactional support, changing the logging and transactional parts of an application may impact all those classes. In addition, mixing logging and transactional code with business logic can make the business-logic part of the code unduly complex.
To alleviate the need for scattering code across many components, aspect-oriented programming (AOP) advocates the separation of such cross-cutting concerns into aspects, and provides facilities to manage how such aspects interact with mainline application code.
While AOP has become a popular technique, some AOP implementations do not adhere to the same type-safety as Java does, for instance. A handful of solutions emerged in recent years to address the need for type-safety in AOP, such as Rickard Öberg's abstract schema for dynamic AOP. More recently, Scala's built-in mixin composition capability is becoming noticed as a way to define type-safe aspects. Jonas Bonér's latest article on real-world Scala, Managing Cross-Cutting Concerns using Mixin Composition and AOP, provides a tutorial into this Scala feature:
Mixin composition is an extremely powerful tool that you can utilize in many different ways to enable modular and reusable code... I’ll try to show you how you can use it to solve the problem of crosscutting concerns using AOP/interceptor-style composition...
A concern is a particular concept or area of interest. For example, in an ordering system the core concerns could be order processing and manufacturing, while the system concerns could be transaction handling and security management. A cross-cutting concern is a concern that affects several classes or modules, a concern that is not well localized and modularized...
Scala’s mixin composition can take place when we instantiate an instance, e.g. it allows us to mix in functionality into specific instances [at] object creation time for specific object instances... Mixin composition stacks is a core language feature of Scala... We will let the Scala compiler statically compiled in an interceptor stack with all our interceptors.
In the article, Bonér describes how Scala composition can be used to implement cross-cutting logging and transaction demarcation, and how such aspects can be mixed into objects in a type-safe manner.
From this blog it sounds like a light version of generic programming (a la C++) although the mix-in occurs at instantation time/run-time rather than compile time. I haven't had a closer look at it though.