I think for our purposes "native integration" means with a Java or .NET library. Native as in C level code, will always be thru the Java or .NET platform, never from Fan directly. I really have no clue what the best solution is, but I have some points to consider for when we get together Sunday.
At the most basic level native integration is either in-line or out-of-line. By in-line I mean that code calling native Java or .NET libraries is inlined right into the Fan source (potentially as Java/C#, but for this discussion assume as Fan code itself). By out-of-line, I mean that the native code is written outside of the Fan source, most likely as pure Java or C# code (this more like the JNI approach). Both approaches have various design options with their own pros and cons.
In-Line:
Easier for small bits of code
Larger integrations can always be wrapped easily (see previous bullet)
Easier to embed into the pod deployable unit
Must have feature if using Fan as better Java/C# (Grooy/Boo)
Needs conditional compile: jcode, ncode blocks (good and bad)
Serious problems dealing with primitives, arrays, delegates, etc?
Out-of-Line
Pain the ass for small bits of integration
Easier to get deep language integration for bigger tasks
Hard to embed into a unified pod deployable unit
Serious problems dealing with dependency issues (auto-generate jar and assemblies to compile against?)
I would say that in-line is easier to use and harder to implement, out-of-line will be easier to implement and harder to use (if we can figure out the dependency issue). Figuring out how to just call Java/.NET libraries from right within Fan is the preferred solution. However I'm not sure we can do that without implementing all the nasty things like primitives and auto-boxing, which seems to negate a lot of stuff we are doing in Fan's type system. First thought is that you can only use that stuff inside a method body to call out to another method. But then what about subclassing native library classes? At the least you need to implement listeners/delegates for callbacks. So if you are going to try to integration in-line, then I don't think you can escape primitives and arrays (and potentially generics in .NET?).
The serious bitch with out-of-bound is how to compile a native Java/C# file against all the Fan code it uses? It gets into a weird two way stubbing problem unless everything in Fan is reflectively called by the Java/C# code. Plus I think this approach makes Fan less attractive in it's main mission - making it easy to write code portable across the JVM and CLR.
One thing that has been nagging at me, is that the current approach to write the sys library just isn't right. A lot of that code really should be in Fan, and we should strive to minimize the duplicate logic required in Java and .NET. So while not a hard requirement, I think any solution we come up with should be applicable to the sys library itself (it's the worst case scenario).
brianMon 27 Feb 2006
Couple of the more complicated use cases we need to solve:
Graphics: consider how to glue Fan's standard Graphics class to it's Java2D or .NET Drawing counterparts. In out-of-bound case you probably need to subclass the Fan Graphics class with a Java/C# implementation. Will need API access to Color, Image, etc.
WebServlet: how to glue Fan's standard servlet APIs to Java Servlet or .NET/IIS/ASP model. This is a complicated case of native code calling out to Fan to create req/resp instances and making callbacks into Fan code to service the request.
brian Sat 25 Feb 2006
I think for our purposes "native integration" means with a Java or .NET library. Native as in C level code, will always be thru the Java or .NET platform, never from Fan directly. I really have no clue what the best solution is, but I have some points to consider for when we get together Sunday.
At the most basic level native integration is either in-line or out-of-line. By in-line I mean that code calling native Java or .NET libraries is inlined right into the Fan source (potentially as Java/C#, but for this discussion assume as Fan code itself). By out-of-line, I mean that the native code is written outside of the Fan source, most likely as pure Java or C# code (this more like the JNI approach). Both approaches have various design options with their own pros and cons.
In-Line:
Out-of-Line
I would say that in-line is easier to use and harder to implement, out-of-line will be easier to implement and harder to use (if we can figure out the dependency issue). Figuring out how to just call Java/.NET libraries from right within Fan is the preferred solution. However I'm not sure we can do that without implementing all the nasty things like primitives and auto-boxing, which seems to negate a lot of stuff we are doing in Fan's type system. First thought is that you can only use that stuff inside a method body to call out to another method. But then what about subclassing native library classes? At the least you need to implement listeners/delegates for callbacks. So if you are going to try to integration in-line, then I don't think you can escape primitives and arrays (and potentially generics in .NET?).
The serious bitch with out-of-bound is how to compile a native Java/C# file against all the Fan code it uses? It gets into a weird two way stubbing problem unless everything in Fan is reflectively called by the Java/C# code. Plus I think this approach makes Fan less attractive in it's main mission - making it easy to write code portable across the JVM and CLR.
One thing that has been nagging at me, is that the current approach to write the sys library just isn't right. A lot of that code really should be in Fan, and we should strive to minimize the duplicate logic required in Java and .NET. So while not a hard requirement, I think any solution we come up with should be applicable to the sys library itself (it's the worst case scenario).
brian Mon 27 Feb 2006
Couple of the more complicated use cases we need to solve: