Well... there's heaps of Java stuff that could be used that has nothing to do with android... arguably it would be better to find a C library that does the same job and use that but for Java devs that's not going to help much...
Yeah - I realized that was probably the angle you were coming from after posting - and after reading Jan's thread
I don't mind the idea of specifying things in a .lcidl file but still don't see the necessity when it can all be determined at runtime - except for the open language syntax definitions, of course.
Well sometimes uniformity is enough of a reason to necessitate something... The 'only' (albeit reasonably sized) thing you can get from Java at runtime is the methods and their signatures (and classes and fields). This isn't quite enough information to specify the methods from the point of LiveCode (even without Open Language). For example:
Code: Select all
void myTestFunction(String myString, int myInt)
This would have to be interpreted as being a function taking two arguments if you only have Java reflection to rely upon. However, it could be that the intention is that it be specified as:
Code: Select all
command myTestFunction(in myString as optional string, in myInt as optional int default 100)
The point here is that the 'native' signatures (whether that be Java, native code, or LiveCode) don't give quite enough information to be able to determine how the engine should call such a method.
Anyway, there is more to say on this topic (we're moving into the realm of general language bindings - which is quite an exciting idea - why not let people extend LiveCode in any language that is suitably hostable?), but it might better be done in a new thread - besides, I need to explain what the plan is with regards the current way the engine binds to external methods and the existing external interface(s).
