When I say "argument typing", I meant having a single "function" class and leaving the number of arguments to being an implementation detail handled by the type of the argument class. The reason is because function classes usually do some fairly heavy lifting which shouldn't be repeated for the N number of functions.
~~ Robert. John Cowan wrote: > On Sat, May 9, 2009 at 11:06 AM, Robert Fischer > <robert.fisc...@smokejumperit.com> wrote: >> John Cowan wrote: >>>> 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. >>> >> I'd recommend having a Function<ARG_T extends ArgumentType> and abstract >> away the argument typing. > > The language is dynamically typed, so Object really is all there is. > >> ~~ Robert Fischer. >> Grails Training http://GroovyMag.com/training >> Smokejumper Consulting http://SmokejumperIT.com >> Enfranchised Mind Blog http://EnfranchisedMind.com/blog >> >> Check out my book, "Grails Persistence with GORM and GSQL"! >> http://www.smokejumperit.com/redirect.html >> > > > -- ~~ Robert Fischer. Grails Training http://GroovyMag.com/training Smokejumper Consulting http://SmokejumperIT.com Enfranchised Mind Blog http://EnfranchisedMind.com/blog Check out my book, "Grails Persistence with GORM and GSQL"! http://www.smokejumperit.com/redirect.html --~--~---------~--~----~------------~-------~--~----~ 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 jvm-languages+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
