-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C# types as arguments and returns #121
Comments
I would assume in the same way that excel-d and pynih do it: convert at the seams. |
I don't see how excel-d does it. You don't have Excel types that don't exist at the time excel-d was written. Python is dynamic so how do static types from alien code come to be relevant? |
At the moment, they all become Python classes in both python backends. I would expect C# to be similar, with the difference that it has more options for conversion, but since they map to D's interface, class and struct types anyway I don't foresee any problems. |
But wait: this is wrapping C# for D then, right? So the opposite direction of what we're doing. |
It's the opposite direction yes. But lambdas, return types and the ability to replace part of it at a time. |
This is quite different from problems of python and excel. You never get an excel type that wasn't known at the time you wrote autowrap. |
I want to replace step by step a large c sharp codebase. 800k sloc!
I need to be able to take csharp classes and interfaces as parameters and return type. But how?
You could make a ClrClass(T) type. Two stage build. Stage one it just accepts any old opdispatch and generates csharp boilerplate. Stage two the same calls generate D mixin code to hook up to the boilerplate.
Exactly what boilerplate depends. But maybe see what you think of concept.
The text was updated successfully, but these errors were encountered: