Composing features at compile time
Philippe Sigaud
philippe.sigaud at gmail.com
Sun Nov 24 06:15:32 PST 2013
The general problem is to inject code at predetermined points. As Rémy
said, that should remind us of AOP.
I have three other very vague ideas ;-) Not tested in any way.
#1) Create a wrapper, say Interceptor!(Foo, "__ctor", "bar").
Interceptor will act as a Foo, except it will have hooks that are
called before and after any calls to "__ctor" (so Foo.this()) and
Foo.bar.
The good: I imagine the hooks can be changed at runtime. By default,
they do nothing.
The bad: Interceptor!(Foo) is not a Foo anymore. But then, your own
Foo!(option0) is not related to Foo!(option1) also.
Bad #2: no hook inside a method, they are only called before or after a method.
The ugly: the pre- and post-hooks could all have different types :-(
(from void delegate() to... whatever).
#2) Same idea, but the intercepting code is inside Foo (maybe with a
mixin?). The real methods are private, and opDispatch catch the calls,
calls the pre-hook, then the inner method, then the post-hook.
#3) The string mixin road. I know what you're thinking. Learn to love
the strings!
Define Foo only as a string to be compiled, with some points where
string interpolation is possible.
string makeFoo(string hooks()...) { return "struct Foo { " ~ hook[0]() ~ ... }
The good: you can now inject parameterized code anywhere you want into Foo code.
The bad: well, string mixins. You're coding blind.
More information about the Digitalmars-d-learn
mailing list