another question about megamorphic call sites in combination with MethodHandles

[Jochen Theodorou]

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