I'm very new to Fantom, I just recently discovered it and I am loving it's pragmatic approach and feature set while retaining a very conventional C-like syntax.
I was looking through the doc, and one thing I like is the easy interop with Java. It seems most java types can be used as if they were Fantom code. This is pretty nice compared to Scala or even Clojure.
But, there's currently 3 limitations. I was wondering if I could get more context into these.
Multi-dimensional arrays. This one seems to be the worst restriction right now. Though, it doesn't happen that often, I'm curious to know why this is the case? Does Fantom not support a multidimensional construct? Couldn't multidimensional arrays be mapped to any other indexable type?
Subclassing more then one level deep. I'll rarely feel the need to do this, but, again, I'm curious as to why this is a limitation. Does Fantom subclassing works in a way that makes this impossible?
Java overloaded method override. I understand Fantom does not support method overloading, couldn't Java overloads be transformed into default values methods in Fantom when they are a subset of the arguments? And maybe, simply renamed 2, 3, 4, etc. for cases where they are a different set?
Thank You, Looking forward to learn more about Fantom.
SlimerDudeMon 19 Oct 2015
Hi Didibus,
Thanks for posting! I don't do much Java FFI so I can't shed much light on your queries. Though I can say:
Fantom does support multidimensional lists, such as Int[][]. But a Fantom Int is a Java long, so mapping byte[][] from Java to Fantom is pretty tricky!
Fantom supports multilevel sub-classing. The one-level limitation is only when sub-classing a Java class.
The workaround for this, and indeed any other Java related limitation, is to write a small wrapper class in Java that does what you want, then use this wrapper class in Fantom.
Hope this helps!?
brianMon 19 Oct 2015
Just to add to SlimerDude's comments. Basic philosphosy is that if we can't map between Fantom and Java with a fairly elegant solution that doesn't contain hidden performance pitfalls we will support it. But some cases like the ones you listed are a more obscure and don't meet the criteria.
Multi-dimensional arrays.
The multi-dimensional issue is primarily a performance issue. We can map a one dimensional array to a sys::List backed by that array with just one implicit object allocation - so its pretty fast. But there is nothing in Fantom to represent a multidimensional array - the best you could do is map it to a list of lists, but that would have dreadful performance. Better to deal with in native Java code.
Subclassing more then one level deep.
The multi-level subclassing is just a difficult bit that Java FFI classes aren't instantiated like normal Fantom classes which generate a static factory method. So two levels of nesting creates a situation where they are FFI and need to use Java constructor protocol, but we don't actually generate that in the first subclass because we want them to look like Fantom classes with a factory method.
Java overloaded method override.
Your suggestion makes sense, but you can't really look at a Java class and know if that is the actual behavior. There are many overrloaded cases where that is not the semantics.
elyashivTue 20 Oct 2015
About the function overloading - just adding a number doesn't really do it - how will you know witch function to call?
You can instead do what c++ compilers do - suffix the function name with some data about the function arguments to distinct them. Of course, you have to be careful, so you don't generate new collisions - if you have functions f(int a) and f(String s) that are mapped to f_I(Int a) and f_S(String s) they will collide with a function names f_I...
Also, theses will kill the backwards compatibility...
didibus Sun 18 Oct 2015
Hi,
I'm very new to Fantom, I just recently discovered it and I am loving it's pragmatic approach and feature set while retaining a very conventional C-like syntax.
I was looking through the doc, and one thing I like is the easy interop with Java. It seems most java types can be used as if they were Fantom code. This is pretty nice compared to Scala or even Clojure.
But, there's currently 3 limitations. I was wondering if I could get more context into these.
Thank You, Looking forward to learn more about Fantom.
SlimerDude Mon 19 Oct 2015
Hi Didibus,
Thanks for posting! I don't do much Java FFI so I can't shed much light on your queries. Though I can say:
Int[][]
. But a FantomInt
is a Java long, so mappingbyte[][]
from Java to Fantom is pretty tricky!Hope this helps!?
brian Mon 19 Oct 2015
Just to add to SlimerDude's comments. Basic philosphosy is that if we can't map between Fantom and Java with a fairly elegant solution that doesn't contain hidden performance pitfalls we will support it. But some cases like the ones you listed are a more obscure and don't meet the criteria.
The multi-dimensional issue is primarily a performance issue. We can map a one dimensional array to a sys::List backed by that array with just one implicit object allocation - so its pretty fast. But there is nothing in Fantom to represent a multidimensional array - the best you could do is map it to a list of lists, but that would have dreadful performance. Better to deal with in native Java code.
The multi-level subclassing is just a difficult bit that Java FFI classes aren't instantiated like normal Fantom classes which generate a static factory method. So two levels of nesting creates a situation where they are FFI and need to use Java constructor protocol, but we don't actually generate that in the first subclass because we want them to look like Fantom classes with a factory method.
Your suggestion makes sense, but you can't really look at a Java class and know if that is the actual behavior. There are many overrloaded cases where that is not the semantics.
elyashiv Tue 20 Oct 2015
About the function overloading - just adding a number doesn't really do it - how will you know witch function to call?
You can instead do what c++ compilers do - suffix the function name with some data about the function arguments to distinct them. Of course, you have to be careful, so you don't generate new collisions - if you have functions
f(int a)
andf(String s)
that are mapped tof_I(Int a)
andf_S(String s)
they will collide with a function namesf_I
...Also, theses will kill the backwards compatibility...