On Wed, May 6, 2009 at 2:37 PM, John Rose <[email protected]> wrote:
> I think grouping > methods in a switch is the state of the art before JDK 7. Okay. *sigh* > Depending on your schema of call types, you'll want to choose between > grouping call types on interface types vs. one call type per interface > type. Since the arguments and returns are all Object, I think all I need is one class per arity: Function0, Function1, Function2, ... FunctionN, which last takes an Object[] of arguments. > Interface types can be true Java interfaces, or Java abstract > classes with factored default error-reporting or adapting behaviors. I don't follow you. Can you explain how this fits with the model I posted? (Note that the static methods don't actually have to be in this class at all; that was just the simplest thing pedagogically.) I think you mean that the Functionx classes can be a subclass of an abstract Function class which implements throwing versions of invoke0, invoke1, invoke2, ... invoken, so as to catch calls with too many or too few arguments. Is there something I'm missing? -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
