On Dec 7, 2007 8:01 AM, Jim White <[EMAIL PROTECTED]> wrote: > > I hope that list gets used multiple times. Otherwise it would be better > performance-wise (particularly wrt garbage), at the expense of somewhat > more convoluted code since we don't have continuations, to just search > for the nearest match (with a flag for the multiple match condition) > rather than building a list. > > The important thing is to make sure that the prospective method list for > every case is clearly specified and documented. Ditto for the > precedence calculation.
There's another dimension of complexity here. In most dynamic languages you can add and remove methods from classes at runtime. In Groovy a class can have different sets of methods at the same time in different threads. So if you build a list and try to reuse it you have to check that the list is still valid. This check can be quite expensive. In Ng I have an object per method. The are classified by name and by number of parameters.I don't build a list. For each class in the hierarchy I go through each possible method object and make a call which says "for this set of parameters how much would it cost to make the call". If the answer is 0 I make the call immediately (via a method on the method object). If the cost is >0 I continue with the next possible method. I then make the call via the method object which has submitted the lowest bid. If two methods make the same bid I chose the one in the class closest to the original class (i.e. if foo on MyClass and on Object both bid 1 I call foo on MyClass). My current view is the problem of dispatching a method call when there are multiple candidates is fascinating but not vital to performance, The important thing is to dispatch a call where there is only one possibility as fast as possible. Of course calling Closures does not require all this palaver. John Wilson --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
