Is there a way to extract the source code of a method at compiletime?

On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:
> Is there a way to extract the source code of a method at compiletime?

Short and to the point answer: no.

On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:
> Is there a way to extract the source code of a method at compiletime?

Nope. What do you need to do?

On Saturday, 26 October 2013 at 19:04:09 UTC, Gary Willoughby wrote:
> On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:
>> Is there a way to extract the source code of a method at compiletime?
>
> Nope. What do you need to do?


I'm currently making an AOP framework. I use UDA's to handle logging, exception handling ect.

It looks something like this currently.

class Foo : IFoo
{
    @Log("bar.txt") @DLLException()
    void bar(...params...)
    {
      //dosomething
    }
}

unittest
{
   alias TypeTuple!(LogWrapper, DLLExeWrapper, ...) wrappers;

   //Normal foo
   auto fooProto = new Foo();

   //Wrapped foo having some nice extra functionallity for Foo.bar
   IFoo foo = new wrap!(Foo, IFoo, wrappers)(fooProto);
}

Currently the wrappped foo delegates to fooProto aswell as adding the functinallity specified by the UDA's. I basically wanted to remove the
delegation. And just put the source code in the newly created foo specialisation.

On Saturday, 26 October 2013 at 20:38:14 UTC, TheFlyingFiddle wrote:
> On Saturday, 26 October 2013 at 19:04:09 UTC, Gary Willoughby wrote:
>> On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:
>>> Is there a way to extract the source code of a method at compiletime?
>>
>> Nope. What do you need to do?
>
>
> I'm currently making an AOP framework. I use UDA's to handle logging, exception handling ect.
>
> It looks something like this currently.
>
> class Foo : IFoo
> {
>     @Log("bar.txt") @DLLException()
>     void bar(...params...)
>     {
>       //dosomething
>     }
> }
>
> unittest
> {
>    alias TypeTuple!(LogWrapper, DLLExeWrapper, ...) wrappers;
>
>    //Normal foo
>    auto fooProto = new Foo();
>
>    //Wrapped foo having some nice extra functionallity for Foo.bar
>    IFoo foo = new wrap!(Foo, IFoo, wrappers)(fooProto);
> }
>
> Currently the wrappped foo delegates to fooProto aswell as adding the functinallity specified by the UDA's. I basically wanted to remove the
> delegation. And just put the source code in the newly created foo specialisation.

I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.

> I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.

Hmm i never considered inheritance actually...
(I'm to used to the decorator pattern i guess ^^,
 Normally i only inherit from interfaces and decorate)

But now that you pointed it out it's a perfect fit!
Thanks for the help.

On Saturday, 26 October 2013 at 22:56:20 UTC, TheFlyingFiddle wrote:
>> I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.
>
> Hmm i never considered inheritance actually...
> (I'm to used to the decorator pattern i guess ^^,
>  Normally i only inherit from interfaces and decorate)
>
> But now that you pointed it out it's a perfect fit!
> Thanks for the help.

You can use decorator the same way too.

On Sunday, 27 October 2013 at 09:00:24 UTC, QAston wrote:
> On Saturday, 26 October 2013 at 22:56:20 UTC, TheFlyingFiddle wrote:
>>> I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.
>>
>> Hmm i never considered inheritance actually...
>> (I'm to used to the decorator pattern i guess ^^,
>> Normally i only inherit from interfaces and decorate)
>>
>> But now that you pointed it out it's a perfect fit!
>> Thanks for the help.
>
> You can use decorator the same way too.

Can you provide a simple example please?

>> Hmm i never considered inheritance actually...
>> (I'm to used to the decorator pattern i guess ^^,
>> Normally i only inherit from interfaces and decorate)
>>
>> But now that you pointed it out it's a perfect fit!
>> Thanks for the help.
>
> You can use decorator the same way too.

Yes i know and that was what i was doing initially, however in this specific case its unessasary and provides a little more extra bagage then simply inheriting.

You get two objects instead of one => More cache locality problems aswell as more potential garabage the garabage collector needs to keep track of. (is this relevant? You never know. If i create 10000+ objects this way it's kinda relevant)

The main problem with this approach for me is that i can't make the classes i write final. It's not rly a hard thing to do but it breaks a force of habit.

On Sunday, 27 October 2013 at 14:34:14 UTC, Gary Willoughby wrote:
> Can you provide a simple example please?
Just the same way you generate code for inheritance you can use to generate code for composition. You just call <membername>.method instead of super.method.

I don't know if anyone can call that a simple example, but it's all i have by hand:
https://github.com/QAston/DMocks-revived/blob/master/dmocks/object_mock.d
I use this technique to mock structs and final classes.