Attila Szegedi schrieb: > > On 2007.12.07., at 9:11, Charles Oliver Nutter wrote: > >> Jochen Theodorou wrote: >> ... >>> 1) build a list of all methods with the name of the method we want >>> to calls >>> 2) remove the methods that are not valid for the call >>> 3) if more than one method remains calculate the "method distance" >>> between the call and the method >>> 4) the method with my minimum distance will be selected >>> 5) if at the end I have two or more methods with the same minimum >>> distance I have to report an error >> ... >>> So.. how do other languages do that? >> I'm not going to try to describe the JRuby way, because it's not >> nearly >> as good as we'd like it. What I would like to do is say we need "one >> way" we can use to do this method selection and dispatch in all our >> languages. >> >> Attila mentioned that he had been working on a library to do dynamic >> dispatch on Java types according to the specified behavior that javac >> follows for static dispatch, and I presume he meant the MOP library >> that's now available in release form. If that's the case, it would >> be an >> additional, very compelling reason for us to try to back that >> library by >> implementing the interfaces in our language impls. > > Yup, it's all implemented. See > > <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/dynalang/src/org/dynalang/mop/beans/ > > > > > OverloadedDynamicMethod is the class you're looking for. It further > relies on both OverloadedFixArgMethod and OverloadedVarArgMethod, > which implement the actual nitty-gritty details for fixedarg overloads > and vararg overloads of a method, respectively.
I must say I don't get it fully yet.. If I look at OverloadedMethodUtilities#isMoreSpecific then I see two classes involved and this tells if one is more specific than the other.. so I would have expected to find a usage where you try to sort a set ci into for example c1<c2<c3 with c3 being the call argument class and c11/c2 being classes from two available method.. but I don't find a place where this happens. Instead I think I you just compare the method parameters to find the most specific method.. but not the method "most fitting" the call... So coming back to my c1,c2,c3 this is all fine if you assume that c2<c3 and c1<c3, because the most specific one will then be the "most fitting" one too. But I don't find the place where the filtering happens. ah yes, one more thing.. isn't your marshalTypes and selectorCache in OverloadedFixArgMethod a good place for memory wholes? bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
