On Jan 17, 2008 5:48 PM, John Cowan <[EMAIL PROTECTED]> wrote: > > On Jan 17, 2008 6:30 AM, John Wilson <[EMAIL PROTECTED]> wrote: > > > One thing I have considered is aggregating all these > > closures/lambda/etc in a compilation unit as static methods on a > > single class. This means that you amortise the cost of a classloader > > over several methods. Instances of the function object delegate to the > > static method. The cost is, obviously, delayed GC of the "mothership" > > class. Of course, if you can dynamically create new functions this > > won't help. > > That's what I'm doing. Function is an abstract class rather than a > marker interface, and it provides a field named _index. If Foo is a > subclass of Function that has five static methods, then there are also > five static fields initialized to five instances of Foo with _index > values from 0 to 4; these represent at source-language level the five > possible functions (in general, there may be more than one Foo per > source-code module, but one is typical). > > So if you invoke the _invoke method (the only instance method of these > classes) on a particular Foo object, it will run a switch statement > that validates the number of passed arguments and calls the > appropriate static function. This is only done, of course, when the > function to be invoked is not known at compile time; otherwise, the > static method is called directly.
I plan to have a single, concrete class for all functions which are objects (Lambdas and Closures, in my case). It contains a reference to a java.lang.reflect.Method (which allows it to call the static method) and some optional state. The calls from Ng all go via the MetaClass of this wrapper class and just cause the static method to be called via reflection (passing the state with the parameters). There is an invoke() method for calls from Java. This means I can add an arbitrary number of method bodies to a class and treat them all as separate functions. 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 jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
