Honouring Implemented Interfaces

Jan 28, 2010 at 3:05 AM
Edited Jan 28, 2010 at 3:09 AM

Hi there,

I was wondering whether or not you had made any further progress with #27 yet, even if it were in terms of design considerations. I've recently started trying to use Jolt's code generation features in a project that I'm working on, and have found it to be quite helpful. However, I've come across a couple of design road blocks due to this issue, and would be keen to see it resolved. On that note, I'm unsure as to how actively you maintain this project or what kind of community contribution would be welcomed (excuse me if I've missed something obvious here, I'm very new to this whole codeplex business).

Anyways, if you've solved the problem, but not yet had the time to implement it, I'd be keen to help. If not, I'd also be keen to help finding a solution, or at the very least starting up a discussion here about the issue and potential ways to solve it.

P.S. Thanks for all of the hard work you've put in on Jolt so far, it's fantastic!

Coordinator
Jan 30, 2010 at 2:46 AM
Edited Jan 30, 2010 at 2:49 AM

Hello angolon!
Thank you for posting your question with your feedback.
Coincidentally, I was thinking about this very problem a few weeks ago while implementing the circular collections that were committed last week.  It turns out that I need this very feature to cleanly implement a collection adaptor, but in its absence resorted to creating the adaptor manually.
I've reviewed my notes on the issue and believe I have a solution, which follows this algorithm.
  • Add a new method to the ProxyTypeBuilder class that accepts an interface that the resulting proxy/interface pair will implement
    • It must be a valid interface that is specified on the real subject type
    • ProxyAssemblyBuilder will call this method for each interface implemented by the real subject type
  • For each method on the given interface, add an approriate forwarding method on the generated proxy type
    • We use Type.GetInterfaceMap() and InterfaceMap.TargetMethods to find the method that the proxy needs to forward to
    • If the method is already present, emit a warning and ignore it
  • Compile proxy and interface types
    • Any problems will be due to the caller adding ambiguous methods; though if the algorithm is specific in detecting duplicate methods, I can't see how this will ever happen.

This is a pretty straightforward solution that should work, supporting both generic and implictly/explicitly implemented methods.  Do let me know what you think of this approach!

On a side note, I've since reviewed my blog post that initially described the complexity of this problem and now realize I got it all wrong.  I was intending on adding all the required interfaces to the proxy first, then trying to match methods given by users with those that the interfaces require.  This approach doesn't make much sense now, since it is possible for the generated type to be in an incosistent state (i.e. missing method implementations).
In the mean time, I've moved the work item into the next release bucket, but can't say when it will be completed and tested.  Hopefully I can get to it in February.
Coordinator
Jan 30, 2010 at 2:48 AM
Edited Jan 30, 2010 at 2:48 AM

To answer your question about community involvement, I am open to accepting contributions.

The most straightforward way to contribute fixes and enhancements is to submit a patch using the facility on the source code page.  I'll be emailed by CodePlex noting the new patch, and then I may incorporate it into the source tree after reviewing it.