Difference between revisions of "Java integration planning"
(New page: '''this information is NOT up to date''' How to handle Java interop? How to handle calling of methods with interfaces? Closure conversion would be nice indeed. Maybe use a call to [] to s...) |
|||
| Line 1: | Line 1: | ||
| − | ''' | + | '''This information is for Ioke E+''' |
| − | + | Java classes can be accessed by their full name, separated with colon instead of dots: | |
<source lang="ioke"> | <source lang="ioke"> | ||
| − | + | h = java:util:HashMap new | |
| − | |||
| − | |||
</source> | </source> | ||
| − | + | You can invoke methods as expected, although the rules for this are a bit intricate. Specifically, the rules are that when calling methods that take any kind of primitive arguments (most of the types in java.lang), these values will be unwrapped. That means for a method taking an int, you can send in a wrapped Java Integer, but you can also send in an Ioke Number Rational, and it will be unwrapped correctly. You can send Text and Symbol to methods taking Strings. | |
| − | < | + | If you send in data to a method taking Object, you will not get the expected result in all cases. Specifically, in these cases Ioke will unwrap wrapped Java objects, but will not coerce the primitive types. So doing <code>h put("foo", "bar")</code> will not coerce Text into java.util.String. However, if you have a java.lang.String that has been modified from the Ioke side - adding cells for example, then that String will be unwrapped before sent to the method call. |
| − | + | ||
| − | </ | + | The return value from a Java invocation will never be modified, except that null will always be changed into nil. This means that if you wrap a Java object, do some modifications to it, and then let it go through a Java call, what you will get back is probably not the wrapped version of that object. Of course, later on if you try to call a method on the object, you will still use the wrapped data. |
| − | + | The general rule for overloading is that overloaded methods will be sorted from the most specific to the most general. | |
Revision as of 16:12, 7 February 2009
This information is for Ioke E+
Java classes can be accessed by their full name, separated with colon instead of dots:
h = java:util:HashMap new
You can invoke methods as expected, although the rules for this are a bit intricate. Specifically, the rules are that when calling methods that take any kind of primitive arguments (most of the types in java.lang), these values will be unwrapped. That means for a method taking an int, you can send in a wrapped Java Integer, but you can also send in an Ioke Number Rational, and it will be unwrapped correctly. You can send Text and Symbol to methods taking Strings.
If you send in data to a method taking Object, you will not get the expected result in all cases. Specifically, in these cases Ioke will unwrap wrapped Java objects, but will not coerce the primitive types. So doing h put("foo", "bar") will not coerce Text into java.util.String. However, if you have a java.lang.String that has been modified from the Ioke side - adding cells for example, then that String will be unwrapped before sent to the method call.
The return value from a Java invocation will never be modified, except that null will always be changed into nil. This means that if you wrap a Java object, do some modifications to it, and then let it go through a Java call, what you will get back is probably not the wrapped version of that object. Of course, later on if you try to call a method on the object, you will still use the wrapped data.
The general rule for overloading is that overloaded methods will be sorted from the most specific to the most general.
