我认为这是可能的,但它需要大量的语言规范的补充,这是没有道理的。
首先,对于你枚举的例子,你可以使用Class扩展枚举>>选项。
Class?还有另一个问题?扩展枚举>选项:因为Enum.class是Class&Enum>这是一个Class扩展枚举>选项= Enum.class是合法的
这不会发生在Class>选项,因为枚举不是枚举的子类型,而是混乱的原始类型处理中相当意外的事实。
回到一般的问题。由于在有限的属性类型中,Class是唯一一个具有类型参数的通配符,通配??符通常表达力足够,您的关注不是非常值得寻求的。
让我们进一步推广这个问题,假设有更多的属性类型,通配符在许多情况下都不够强大。例如,假设允许地图,例如
Map options();
options={"a":1, "b":2} // suppose we have "map literal"
假设我们希望一个attrbite类型是Map< x,x>任何类型的x。这不能用通配符表示 – Map意味着Map< x,y>对于任何x,y。
一种方法是允许类型为:< X> Map< X,X>的类型参数。这实际上是非常有用的一般。但这是系统的重大改变。
另一种方法是重新解释注释类型中方法的类型参数。
Map options();
options={ "a":"a", "b":"b" } // infer X=String
在目前的方法类型参数,推理规则,继承规则等的理解中,这根本不起作用。我们需要改变/添加很多东西才能使其工作。
在任一方法中,如何将X传递给注释处理器都是一个问题。我们必须发明一些额外的机制来携带具有实例的类型参数。