Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6261279

Variable number of generic parameters to a class


    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Not an Issue
    • Affects Version/s: 5.0
    • Fix Version/s: None
    • Component/s: specification
    • Subcomponent:
    • CPU:
    • OS:


      In jga (http:/jga.sf.net), I'm forced to support several flavors of some of the key functors, with different numbers of generic parameters. For example, at this point there are three different forms of Constant -- as a Generator, a UnaryFunctor, and a BinaryFunctor.

      I'd like to be able to get to having a single root Functor class that all specific functors derive from. I imagine the syntax would be

      public class Functor<ReturnType, ArgType...> {
          public ReturnType exec(ArgType... args);

      and the three main classes in jga would be

      public class Generator<ReturnType>
              extends Functor<ReturnType>
          public ReturnType exec() { }

      public class UnaryFunctor<ReturnType,ArgType>
              extends Functor<ReturnType,ArgType>
          public ReturnType exec(ArgType arg) { }

      public class BinaryFunctor<ReturnType,Arg1Type,Arg2Type>
              extends Functor<ReturnType,Arg1Type,Arg2type>
          public ReturnType exec(Arg1Type arg1, Arg2Type arg2) { }

            The compiler would have to tie together the general varags placeholder in the set of generic parms with the overridden implementations, and enforce that the number and types as overridden are consistent with those declared in the basetype.

            A couple concrete examples:

      public class Constant<ReturnType, ArgType...>
             extends Functor<ReturnType, ArgType...>
          private ReturnType r;
          public Constant(ReturnType r) { this.r = r; }

          public ReturnType exec(ArgType... args) { return r; }

            In this declaration, the ArgType... construct is repeated in the local class declaration, so that form is retained in the signature of the interface's method.

      public class Less<ArgType>
              extends Functor<Boolean, ArgType, ArgType>
          public Boolean exec(ArgType arg1, ArgType arg2) {}

            In this form, the ArgType... construct is replaced with two instances of some type, so the interface method takes a pair of values of the parm type.

      public class Foo
              extends Functor<Date, String, Point, Number...>
          public Date exec(String str, Point pt, Number... nums) {}

            It should work for more exotic combinations as well. I've been working on extending jga with VariableFunctors: it would allow the language parsed by the FunctorParser to contain any number of unknowns in the expressions rather that the 0, 1, or 2 that it is currently restricted to. Unfortunately, this will lead to still more duplicate implementations of a number of functors. In this case, generics is the root of the problem, and I might have to consider abandoning generics in the root functor implementations.

      (see http://www.jroller.com/page/dhall/?anchor=generic_java_wishlist

      This would allow generalization of functor interfaces via a single base functor implementation. A number of commonly used functors have to be reproduced in each of several 'flavors' of functors, varying only in the number of generic parameters.

      This would be very useful in the implementation of the feature requested in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5061325
      "Add language support for functors (function objects)", especially in response to the first

      "Closures would be a huge win,, although I think the suggest approach is problematic and doesn't scale nicely to N-ary functions."

      N-ary functors can't be supported with type-safety without some form of variable generic parm list.
      ###@###.### 2005-04-26 09:05:26 GMT




            • Assignee:
              abuckley Alex Buckley
              jssunw Jitender S (Inactive)
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: