On Sat, Apr 4, 2009 at 6:33 PM, Serabe <[email protected]> wrote: > Hello, everybody, > > * please, take a brief look at > http://blog.headius.com/2009/03/more-compiling-ruby-to-java-types.html > > currently there's is some dirty code that let you generate all > possible java signatures instead of generating just one. The code > doesn't take into account restargs no blocks yet. Anyway, I would like > to know what would you expect from such a method. > > What would you expect in the following case? > > def foo(a,b,*c) with generate_signatures :foo, > [java.lang.String,java.lang.String,java.lang.String,java.lang.String] > => Java::void > > Personally, I would expect the following signatures: > > void foo(String,String) > void foo(String,String,String) > void foo(String,String,String,String)
I would expect a type-error (compile-error?). There are only three arguments and this specifies four. I think signatures need to map straight through between Ruby and Java names. How to bind to restargs should probably default to <type>[] (e.g. String[]), but perhaps there should be a way of assigning via collection types too (perhaps as an option?). > and I should add something like :restarg => true to generate one > signature with varargs. Introspecting Ruby method could give us knowledge of whether we need restargs or not. If you wanted to have a four argument string which fed into that signature you need only add: [java.lang.String,java.lang.String,java.lang.String,java.lang.String] => Java::void def foo4(a,b,c,d) foo(a,c,c,d) end In general, I think having one-to-one mapping between variable names will be less surprising to people. It is easy to compose on Ruby side (like in my example above) to have signatures which are not one-to-one. > Serabe > > P.D. You can tell us if you like generate_signatures or would rather > something like :expand => true in the signature method! -Tom -- Blog: http://www.bloglines.com/blog/ThomasEEnebo Email: [email protected] , [email protected] --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
