Composing features at compile time

[Jacob Carlborg]

On 2013-11-24 15:06, "Rémy Mouëza" wrote:
> This looks like a case study for aspect oriented programming: several
> separated concerns that start to intertwine within your code; if left
> unchecked this could result in some messy code.
>
> In Python, I used reflection and "magic" things and have already used
> the spring AOP in Java that is done with some Aspect classes and
> annotation. I suppose that D could bring the best of both world with its
> compile time reflection and UDA.
>
> But if you are in urgent need for a solution, here is a C++ trick called
> "mixin classes", template classes parameterized on their base class:
>
> interface IFoo {
>      void action ();
> }
>
> class Foo : IFoo
> {
>      this () {}
>
>      void action ()
>      {
>          // perform action
>      }
> }
>
> class FooLogging (T : IFoo) : T {
>      Logger logger;
>
>      this () {
>          logger = new Logger;
>      }
>
>      override void action ()
>      {
>          logger.info("performing action");
>          super.action(); // perform action
>      }
>
> }
>
> void main () {
>      Foo foo;
>
>      static if (logging)
>          foo = new FooLogging!Foo;
>      else
>          foo = new Foo;
>
>      foo.action ();
> }
>
> You get separation of concerns: the logging features are in FooLogging,
> overriding the basic behaviour in Foo; you can add a FooEvent mixin
> class to deal with events and so on to deal with any concerns you need.
>
> The "weaving" is done in the main() function in my example. You could
> prefer to put a big `static if (logging)` in the FooLogging class body
> and always instanciate foo instances with the full chain of mixin
> classes (foo = new FooLogging!(FooEvent!(FooAuthentication!(...!Foo)))),
> or anything else that fits you better.

I thought of doing something similar with template mixins.

> This works nicely if your "aspect" (Logging, Events...) applies on the
> whole action() method. Otherwise, you'll have to cut action() into
> smaller methods that will have to be decorated in the appropriate mixin
> class(es) (as the Strategy design pattern).

Unfortunately logging and events were more of an example, for the real 
usage it's not as easy to add before or after actions.

> I am eager to know if anybody else has a better (or more concise) solution.
> I hope this helps.

-- 
/Jacob Carlborg