Am 22.03.2013 10:35, schrieb Remi Forax: > On 03/22/2013 10:24 AM, Jochen Theodorou wrote: >> Am 22.03.2013 10:11, schrieb Remi Forax: >> [...] >>> I don't think it's a good idea to expose directly method handles to users, >>> it's better to encapsulate it into a Groovy object corresponding to a >>> function or a closure so you can add a bunch of invoke overloads. >> what invoke overloads are you thinking of here? > > traditionnal ones, > invoke(Object) > invoke(Object,Object) > ... > invoke(Object...)
Well, I would probably use different name, to avoid the problem of having a call with a single argument being an Object[] but then done with invoke(Object...), which would use the array elements as arguments instead of the array itself. We have this problem in Closure#call already, if done from Java... Which is why the method will go. Our groovy.lang.Closure will become only a thin wrapper ideally. Anyway... so you suggest having a general class we can use for invocations, then make some method to request the invoker, which will produce a subclass, with an implementation that can call the target? bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
