Method/Constructor references.
Srikanth S Adayapalam
srikanth_sankaran at in.ibm.com
Sat Feb 16 10:55:51 PST 2013
(1) 0.6.1, 15.28 says:
"It is a compile-time error if the ClassType of a constructor reference
denotes a class that is an enum type or that is abstract. "
While JLS7 15.9 in addition says:
"It is a compile-time error if any of the type arguments used in a class
instance
creation expression are wildcard type arguments (§4.5.1)."
So is the less restrictive version with constructor references intentional
? I don't see anything in
the design/motivation section regarding this to determine if it is.
I would like to use one definition of what can be instantiated unless the
relaxation is deliberate.
So, should the following program compile ?
// ---
interface I {
X<?> zoo(int x, String p);
}
public class X<T> {
X(int x, String p) {}
I i = X<? extends String>::new; // will compile
X<?> x = new X<? extends String>(); // will not compile.
}
I don't see a type safety issue here since the parameterization would have
pass bounds check, only a consistency issue.
(2) And since the production for ClassType (despite the name) cannot prune
type variables and
annotation types, should these also be called out as error scenarios ?
(3) Should the (obvious) point about primary evaluating to base type being
a forbidden scenario
be mentioned ?
(4) "The immediately enclosing instance of an inner class instance (15.9.2
) must be provided for a constructor reference by a lexically enclosing
instance of this (8.1.3). "
Is this restrictive ? Can this be supplied at method invocation time or
even via a primary from ? Implementable != useful and
I don't have an assessment as to how useful practically it would be
though. Again this is a consistency issue: the call to
new Inner() can occur outside of the enclosing class in an entirely
unrelated class as long as there an enclosing instance is
available and the types are visible.
Srikanth
More information about the lambda-spec-observers
mailing list