Is planed support of decorators?

[harrison314]

Is planed support of Decorator pattern with compile time generation for hig performace scenarios?

Eg:

    [CompilerGenerated]
    partial class ICalculatorAvatar : ICalculator, IAvatarDecorator<ICalculatorAvatar>
    {
        readonly BehaviorPipeline pipeline = BehaviorPipelineFactory.Default.CreatePipeline<ICalculatorAvatar>();
        ICalculatorAvatar IAvatarDecorator<ICalculatorAvatar>.Parent {get; set;}

        [CompilerGenerated]
        IList<IAvatarBehavior> IAvatarDecorator<ICalculatorAvatar>.Behaviors => pipeline.Behaviors;

        [CompilerGenerated]
        public int Add(int a, int b) => pipeline.Execute<int>(new DecorateMethodInvocation(this, MethodBase.GetCurrentMethod(), 
            invocation => Parent.Add((int)invocation.Arguments[0], (int)invocation.Arguments[1]),
            a, b));

        //... 
    }

See also API in my implementation of runtime decorator decorator https://github.com/harrison314/MassiveDynamicProxyGenerator#generate-decorator.

[kzu]

I created a sample that shows how you can invoke another target, which could be used for something like this.

The tricky part about this is that for a simple case like the one you show above it's simple. But what if the type you're decorating is also the base class? What if some members are virtual but not others? What if you specified multiple interfaces?

Maybe decorating is only enabled for interfaces?

I think instead of a decorator interface and setter, it might be simpler to just generate a ctor receiving the interface(s) as targets, and modify the generated code to invoke that if non-null at the call-site, like:

public int Add(int x, int y) => pipeline.Execute<int>(MethodInvocation.Create(this, MethodBase.GetCurrentMethod(), 
  calculator != null 
    ? (m, n) => m.CreateValueReturn(base.Add(x, y), m.Arguments) 
    : (m, n) => throw new NotImplementedException(),
   x, y));

[harrison314]

I created a sample that shows how you can invoke another target, which could be used for something like this.

Dynamic call methods are of the order of magnitude slower.

The tricky part about this is that for a simple case like the one you show above it's simple. But what if the type you're decorating is also the base class? What if some members are virtual but not others? What if you specified multiple interfaces?

Understand. That's why I only allowed interface decoration in my library. I mean is it cleaner.

Maybe decorating is only enabled for interfaces?

Yes, I agree. (Maybe it will extend to classes in the future, if SourceGeneraors have a stronger API.)

I think instead of a decorator interface and setter, it might be simpler to just generate a ctor receiving the interface(s) as targets, and modify the generated code to invoke that if non-null at the call-site, like:

I think that may be the case.

[kzu]

Seems like worthy improvement. I was going to call it v1, but now I'm not sure it should ship without this... Do you think you could perhaps help to bring the feature into v1?

[harrison314]

Do you think you could perhaps help to bring the feature into v1?

I'd be happy to help.
But I don't have the expertise to write generators.