Interface Support...

[GammaSoul]

Hi, does this library have support for generating types that implement an interface, as well as its usual sub classing features?
This could be used to implement many different common interfaces but using the same parent base class dynamically that can be cast to the interface and provide a service backing for the interface.

[ravenpride]

Hi @GammaSoul,

if I understand this correctly, you are trying to implement something like duck casting. A class provides some common properties, methods and events, but it does not implement an interface to access a subset of these members. Is this right?

Duck casting is something you can do with this project. To circumvent issues with sealed classes I would prefer to create a wrapper around an instance of your class rather than dynamically deriving from it. If this is something you want, I can help you to implement it.

[GammaSoul]

Hi @ravenpride. Thank you for getting back to me on this. So yes, a sort of duck casting. But a more strongly typed duck casting. This is not for testing like a Moqing framework, but for production.

I very much like what you have done its not a black box approach like traditional moqing (maybe as its not as big as other frameworks yet ;) ). As everything comes from a defined abstract class and abstract members from that class. There is also a pretty involved initialization process to build the type that you require as well. So its still readable to what is happing and will be going on with the created type. As well as testing the types.

So the idea i have is to use interfaces which inherit other interfaces that are already defined on an abstract base class which have a mix of default and abstract methods/properties. Then a type can be generated which marries the interface and abstract base class. the interface can also have default methods that call methods on the inherited interface defined on the base class that don’t get implemented on the created type but work by calling the methods that are either done manually or are abstract methods created in the new type. using [CallerMemberName] on the base class method i can use that with other things to build very flexible types with this library that are still readable.

So doing it as a wrapper is kind of not what you’re doing now? As the types this system makes are not in a wrapper...
So I’m not sure if the wrapper approach is the way forward... Also it looks like you are able to cache the types that it creates for instantiation as and when needed (could even save to database etc..). This is great as I could build a factory method and use it with dependency injection when the system needs different types based on interface but also scope and state at the time.

What is the performance like to instantiate a created type? Can it be a compiled expression?
I have not tested it I’ve just looked at the demos and codebase

What are your thoughts?

[ravenpride]

Hello @GammaSoul, this sounds interesting. Could you please make small project that demonstrates what you have and what you expect the code generation system to generate for you?

What is the performance like to instantiate a created type?

The performance should be the same as if the compiler has generated the code as the emitted opcodes are JITed as any other .NET MSIL code.

Can it be a compiled expression?

.NET already comes with support for compiling lambda expressions.