On Sat, Mar 14, 2009 at 2:11 PM, Charles Oliver Nutter
<[email protected]> wrote:
> Serabe wrote:
>>
>> Hi, everyone,
>>
>> I've been reading compiler2.rb (I still need to read it two or three
>> times more). I still don't know how to do some details, but here is my
>> idea.
>>
>> signature name, array => return
>>
>> where array is exactly like now but if some parameter is optional,
>> then it is given in the form [class, initial_value]. Just think that
>> brackets are constructors, and it could be even nested like
>> [[MagickImage [BufferedImage, 500, 700]]] => MagickImage would be a
>> method like def a(magick_image=Geometry.new(500,700)) (returning a
>> MagickImage object. My first thought wast to create a optional
>> parameter :optional in the hash with and array of optional parameters.
>> But this wouldn't be valid in Ruby 1.9.
>
> I'm definitely interested in doing optional arguments. They would manifest
> in the Java class as a series of signatures of increasing size. So if you
> defined:
>
> def foo(a = 1, b = 2, c = 2)
>
> There would be four signatures generated from zero to three arguments. Each
> of the lower-arity versions would simply attach their default value and call
> the next larger arity version. That's also how I'd planned to do optional
> arguments in Duby.
>
>> Problems:
>>
>> · Typing too much.
>> · Not the ruby way (it seems Lisp with brackets).
>> · Is overload methods hard in jvm?
>> · How can string objects be introduced in bitescript?
>
> I'm wondering if maybe we could even go a step further and inspect the
> method arguments. So we would expose a real API for getting metadata about a
> method's arguments, and then use that for part of the definition. Right now
> there's absolutely no correlation between the signature you specify and the
> number or type of arguments on the actual Ruby method. If we could inspect
> it, then we could get out optional values, required/optional counts, and so
> on.
Exposing arguments is a great idea and it will be pretty simple to
implement. We could use it to give nicer warnings since we would know
if the signature could not properly dispatch to the underlying Ruby
signature.
signature :foo, [String, int, int] => String
*In an earlier conversation I suggested using a hash for signature
specification, but I retract that since the flexibility will not buy
very much if we accept that the above syntax will always generate all
possible Java overloads. This seems like a reasonable expectation.
We could be more elaborate and specify less than all possible Java
signatures for a Ruby method, but if someone wants to do that they can
make a more restricted ruby method expressly for that purpose.*
def foo(a, b=4, c=5)
end
This would generate:
public String foo(String a) {...}
public String foo(String a, int b) {
IRubyObject rb = JavaToRuby(4);
...
}
public String foo(String a, int b, int c) {
IRubyObject rb = JavaToRuby(4);
IRubyObject rc = JavaToRuby(5);
...
}
Another question will be how to handle more elaborate defaults
signature :foo, [Bar] => int
def foo(a=Bar.foo)
if (a == null)
IRubyObject ra = TC.getConstant("Bar").callMethod("foo")
else
IRubyObject ra = JI.wrap(a)
end
end
Cases:
Bar => IRubyObject (regular Ruby object)
Bar => an existing Java class org.com.Bar
Bar => A Ruby object which has not been compile2'd yet <-- circular
issues if Bar has a method which accepts the class that this signature
is for.
And in this example it makes me also think if we know if the Bar in
signature and Bar in Bar.foo represent the same thing and that Bar has
a foo signature then we can just do static dispatch (or it is a
possibility)...
-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
