Java integration planning - Revision history

Admin: Reverted edits by Icotime (Talk) to last version by Olabini

2010-11-24T14:33:37Z

Reverted edits by Icotime (Talk) to last version by Olabini

Show changes

spambot_Icotime at 01:00, 24 November 2010

2010-11-24T01:00:09Z

Show changes

Olabini at 19:29, 12 February 2009

2009-02-12T19:29:46Z

Olabini at 09:50, 12 February 2009

2009-02-12T09:50:38Z

Olabini at 18:42, 10 February 2009

2009-02-10T18:42:01Z

Olabini at 15:19, 8 February 2009

2009-02-08T15:19:52Z

Olabini at 15:12, 7 February 2009

2009-02-07T15:12:34Z

Olabini: 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...

2009-01-26T20:02:49Z

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...

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 specify that closure conversion is wanted:

<source lang="ioke">
button addActionHandler(fn("hello" println))
button addActionHandler [ "hello" println ]
button addActionHandler {"hello" println}
</source>

Maybe curly braces since it's a language that like this.

<source lang="ioke">
button addActionHandler {e, "hello" println}
</source>

This means that all Java methods need to be macros that check if their next method call is a curlyBracket call.

← Older revision		Revision as of 09:50, 12 February 2009
Line 58:		Line 58:

	And that is why there is a need to have these methods named differently. So, for example, say that you want to invoke the <code>toString</code> method on <code>java:util:HashMap</code>. To do that, you do it like this: <code>java:util:HashMap class:toString</code>. Note that you can actually use the <code>class:</code> methods on instances of a class too. The result will be the same as if the receiver had been that class instead of the instance.		And that is why there is a need to have these methods named differently. So, for example, say that you want to invoke the <code>toString</code> method on <code>java:util:HashMap</code>. To do that, you do it like this: <code>java:util:HashMap class:toString</code>. Note that you can actually use the <code>class:</code> methods on instances of a class too. The result will be the same as if the receiver had been that class instead of the instance.
		+
		+	== Fields ==
		+
		+	Accessing Java fields can be done by prepending the field name with <code>field:</code>. The exact mechanics of this is that a Java field will result in one or two Ioke methods. That means that the fields are not represented as cells directly on the object. If the field is not final, a setter will be also be generated for it. The setter follows the same rules as invocations of regular methods, with regards to casting and choice of unpacking of arguments.
		+
		+	There is a slight gotcha with this scheme. If you try to set a field that is final, you will end up overwriting the accessor for that field - so it's important to be really careful to not set final fields. In the long run, it might be an idea to implement a setter that signals a condition when this happens, but doing that gives the impression that you can set the value - since the setter is there.
		+
		+	Ioke doesn't care if a field is private or protected. All fields are accessible.
		+
		+	A small example - say that you have a java object in <code>foo</code>. This Java object has two fields called <code>oneThing</code> and <code>anotherThing</code>. Then you can work with it like this:
		+
		+	<source lang="ioke">
		+	foo field:oneThing println
		+	foo field:anotherThing = "Bar"
		+	System out println(foo field:anotherThing)
		+	</source>
		+
		+	Note that static fields work the same way - so you can access the Java streams directly like this, for example:
		+
		+	<source lang="ioke">
		+	java:lang:System field:out println("some text")
		+	</source>

← Older revision		Revision as of 18:42, 10 February 2009
Line 23:		Line 23:
	x bar((short) 123, (org:something:Interface)anObj)		x bar((short) 123, (org:something:Interface)anObj)
	</source>		</source>
		+
		+	== Class methods ==
		+
		+	Methods that belong to the Java class java.lang.Class are treated a bit differently from the way other Java methods work. The reason for this is a bit intricate to explain, but basically comes down to the dichotomy between the way mimicking works in Ioke, and the way inheritance works in Java.
		+
		+	The easiest way to explain this might be to take a look at java.util.ArrayList. In Java the hierarchy looks like this (somewhat simplified)
		+
		+	<pre>
		+	instance >> ArrayList -> AbstractList -> AbstractCollection -> Object
		+	-> Serializable
		+	-> Cloneable
		+	-> Iterable
		+	-> Collection
		+	-> List
		+	-> RandomAccess
		+	</pre>
		+
		+	Note here that all capitalized words are names of classes. The Class itself is not part of the inheritance structure, because Java has two namespaces. In Ioke, the above hierarchy basically ends up looking like this:
		+
		+	<pre>
		+	instance -> ArrayList -> Class
		+	-> AbstractList -> Class
		+	-> AbstractCollection -> Class
		+	-> Object -> Class
		+	-> Serializable -> Class
		+	-> Cloneable -> Class
		+	-> Iterable -> Class
		+	-> Collection -> Class
		+	-> List -> Class
		+	-> RandomAccess -> Class
		+	</pre>
		+
		+	This is slightly simplified too, but the basic idea is that Class has to be part of the same inheritance chain, because there only exists one namespace in Ioke.
		+
		+	And that is why there is a need to have these methods named differently. So, for example, say that you want to invoke the <code>toString</code> method on <code>java:util:HashMap</code>. To do that, you do it like this: <code>java:util:HashMap class:toString</code>. Note that you can actually use the <code>class:</code> methods on instances of a class too. The result will be the same as if the receiver had been that class instead of the instance.

← Older revision		Revision as of 15:19, 8 February 2009
Line 14:		Line 14:

	The general rule for overloading is that overloaded methods will be sorted from the most specific to the most general.		The general rule for overloading is that overloaded methods will be sorted from the most specific to the most general.
		+
		+	== Casts ==
		+
		+	Ioke Java integration supporting casts in the same way as Java does. The main difference is that the cast will be evaluated at runtime, not compile time. The name to cast to will be unevaluated. Valid names are either Object, String, any Java class name where dots are separated with colons, and a few special ones to handle primitive values. These names are int, integer, long, short, char, character, float, double and boolean. Casting looks like this:
		+
		+	<source lang="ioke">
		+	x = Foo new
		+	x bar((short) 123, (org:something:Interface)anObj)
		+	</source>

@@ Line 79: / Line 79: @@
 <source lang="ioke">
 java:lang:System field:out println("some text")
 </source>

@@ Line 1: / Line 1: @@
-'''this information is NOT up to date'''
+'''This information is for Ioke E+'''
-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 specify that closure conversion is wanted:
+Java classes can be accessed by their full name, separated with colon instead of dots:
 <source lang="ioke">
-button addActionHandler(fn("hello" println))
+h = java:util:HashMap new
 </source>
-Maybe curly braces since it's a language that like this.
+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.
-<source lang="ioke">
+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.
-button addActionHandler {e, "hello" println}
-</source>
+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.
-This means that all Java methods need to be macros that check if their next method call is a curlyBracket call.
+The general rule for overloading is that overloaded methods will be sorted from the most specific to the most general.