Serabe wrote:
Each signature should hold in some way the following info (at least):
· Ruby method.
· Java method.
· Parameters for the Java method.
· Return value.
· Visibility and such.
· Annotations
I assume annotations would include annotating individual parameters as well.
Do we need to be able to specify generics? Some people really want to be
able to specify generic types from the Java side, and even though it's
meaningless at runtime, it does give you automatic typechecking/casting
on the API exposed via ruby2java.
Visibility I had not considered; generally I see ruby2java as only
really being useful for creating public APIs based on Ruby code. I
suppose being able to specify protected or package visibility would also
be useful.
I tend to agree with Tom that at first only supporting 1:1 mappings
would be nice, except that I'd like to see any method with optional args
produce a couple signatures that automatically support all those
arities. For simplicity we should just support rest args as a
homogeneous Java array, and probably generate bytecode to support them
as Java varargs (this will require an enhancement to Bitescript).
I suggest discussing the first four, choose two or three ideas,
implement them in different branches and start playing a bit with
them.
Have you started any implementation yet? ruby2java is now live in a git
repo on Kenai. We should look at getting a simple 0.0.1 release out this
week based on what we have now, cleaned up an error-proofed a bit.
Starting points:
· If you can call the ruby method with n parameters, then you can make
a Java method with n parameters (note that the implication is one way
only).
I understand this mapping, but I think we should just get array/varargs
working for rest args right now on the backend. Of course, once we have
that working, if you want to continue on and mock up a more advanced
version, there's nothing stopping you :)
· One should be able to generate a signature knowing only the ruby
method name, the type of the params and the retval.
Yes, that seems reasonable.
Preferences:
· Java method name is the same as ruby method, unless stated otherwise
(by the same, I mean that find_by_name would be findByName).
0.0.1 could just require that the method name *always* be used as the
Java name. We can add smarts for providing a new name later.
I figure most people wanting to generate a Java type for a Ruby method
would (at least initially) be fine with calling the Ruby-cased name or
writing the Java-cased name in the code.
· An option to generate multiple signatures for one ruby method should be given.
This lead me to what I said. Anyway, I think that currently the code
is small enough to make two or three branches with the main ideas and
play a bit (I don't know if I've said already this).
I'd like to see what you have.
We also need to start looking at specs/tests for this. There's basically
no tests other than the examples at the the moment. 0.0.1 probably
shouldn't publish any features we don't have specs/tests for. And docs :)
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
