I'm considering using Fan to build a library for both CLR and JVM. However, my library would need to permit users to subclass some of the exposed objects. So, I'm wondering, two things: how are classes exposed to the underlying VM, is it possible for developers to subclass those objects, and finally, is it possible for Fan to create an instance of those subclasses.
Thank you.
brianSat 13 Jun 2009
That is definitely the goal of Fan, although we are probably missing one key feature you need: .NET FFI to access normal .NET libraries from Fan (basically to fill the role as Java FFI fills today).
Assuming we had that, then Fan classes look like normal Java or C# classes. Although there are caveats:
if you use an Fan classes like Duration or DateTime, then those classes come from Fan's sys library (not whatever the built-in representation might be). Strings, integers, etc are native to Java/C# - AKA, sys::Str is java.lang.String or System.String
right now packages/namespace of Fan pods are fixed as "fan.{podName}" (something we need to discuss a strategy for)
some features on't have a direct mapping to Java or C# such as functions or mixins with concrete methods (but you can just avoid those pretty easily in your public API)
Right now Andy and my focus has been on JavaScript portability, so it would be great to find some help with .NET FFI.
JohnDGSat 13 Jun 2009
Related question: a fully abstract mixin -- is this translated into an interface?
brianSat 13 Jun 2009
Related question: a fully abstract mixin -- is this translated into an interface?
Yes, a mixin translates to an interface. Then if you have concrete methods, they are mapped to static methods on a class:
mixin Foo
{
Int incr(Int i) { ++i }
}
class Bar : Foo {}
Translates into Java as:
interface Foo
{
long incr(long x)
}
class Foo$
{
static long incr(Foo self, long i) { return ++i }
}
class Bar implements Foo
{
long incr(long i) { return Foo$.incr(this, i) }
}
cceSat 13 Jun 2009
Thank you for your response. The use of mixins is particularly attractive, would this be supported? Would mixins written in Java/.NET be possible?
Besides regular string operations, regular expressions, socket/file handling, the two primary interfaces our library would need is a web server gateway and a database gateway to Oracle, PostgreSQL. While I'm building my wish list... cross language binding to sqlite would be exceptionally cool. I assume that some of these are still in development.
Finally, when is your target for a stable release targeting both JVM/CLR -- and would adding a competent resource for a few months help?
Best,
Clark
P.S. The javascript target is also quite juicy ;)
brianSat 13 Jun 2009
The use of mixins is particularly attractive, would this be supported? Would mixins written in Java/.NET be possible?
Mixins are just interfaces with an extra class for the concrete stuff. Ideally for Java/C# interop you would keep everything abstract since concrete methods in interfaces isn't really native to Java or C# without manually wiring everything up.
Besides regular string operations, regular expressions, socket/file handling, the two primary interfaces our library would need is a web server gateway and a database gateway to Oracle, PostgreSQL.
Regexs mostly work (discussion under way to ensure they are portable). Sockets are done for both environments. SQL in JVM uses JDBC (so anything that has JDBC driver). We still need .NET SQL impl. Fan standardizes on web as standard servlet API. We have our own simple web server called wisp. Cheeser has it running in GlassFish also. Ideally we'd want an IIS binding also.
Finally, when is your target for a stable release targeting both JVM/CLR -- and would adding a competent resource for a few months help?
I'd like to lock stuff down in the next few months, then have a long beta period to work out the kinks.
We could definitely use help flushing out .NET support such as SQL, IIS binding, and FFI.
cce Sat 13 Jun 2009
I'm considering using Fan to build a library for both CLR and JVM. However, my library would need to permit users to subclass some of the exposed objects. So, I'm wondering, two things: how are classes exposed to the underlying VM, is it possible for developers to subclass those objects, and finally, is it possible for Fan to create an instance of those subclasses.
Thank you.
brian Sat 13 Jun 2009
That is definitely the goal of Fan, although we are probably missing one key feature you need: .NET FFI to access normal .NET libraries from Fan (basically to fill the role as Java FFI fills today).
Assuming we had that, then Fan classes look like normal Java or C# classes. Although there are caveats:
sys::Str
isjava.lang.String
orSystem.String
Right now Andy and my focus has been on JavaScript portability, so it would be great to find some help with .NET FFI.
JohnDG Sat 13 Jun 2009
Related question: a fully abstract mixin -- is this translated into an interface?
brian Sat 13 Jun 2009
Yes, a mixin translates to an interface. Then if you have concrete methods, they are mapped to static methods on a class:
Translates into Java as:
cce Sat 13 Jun 2009
Thank you for your response. The use of mixins is particularly attractive, would this be supported? Would mixins written in Java/.NET be possible?
Besides regular string operations, regular expressions, socket/file handling, the two primary interfaces our library would need is a web server gateway and a database gateway to Oracle, PostgreSQL. While I'm building my wish list... cross language binding to sqlite would be exceptionally cool. I assume that some of these are still in development.
Finally, when is your target for a stable release targeting both JVM/CLR -- and would adding a competent resource for a few months help?
Best,
Clark
P.S. The javascript target is also quite juicy ;)
brian Sat 13 Jun 2009
Mixins are just interfaces with an extra class for the concrete stuff. Ideally for Java/C# interop you would keep everything abstract since concrete methods in interfaces isn't really native to Java or C# without manually wiring everything up.
Regexs mostly work (discussion under way to ensure they are portable). Sockets are done for both environments. SQL in JVM uses JDBC (so anything that has JDBC driver). We still need .NET SQL impl. Fan standardizes on
web
as standard servlet API. We have our own simple web server called wisp. Cheeser has it running in GlassFish also. Ideally we'd want an IIS binding also.I'd like to lock stuff down in the next few months, then have a long beta period to work out the kinks.
We could definitely use help flushing out .NET support such as SQL, IIS binding, and FFI.