call operator and orthogonality with existing VM internals

Jakob Praher jp at hapra.at
Tue Mar 9 15:22:41 PST 2010


Neal Gafter wrote:
> On Tue, Mar 9, 2010 at 9:24 AM, Jakob Praher <jp at hapra.at> wrote:
>   
> Which is why BGGA provides a special syntax for function types that
> inserts the wildcards for you.
>
>   
When talking about Java on the whole (not the feature of adding function
types), it might make sense to add support for covariant/contravariant 
annotations on types? Maybe it is enough to be able to use wildcards
inside interface defintions:

For instance
   interface Function1<? extends R,? super T1> { ... }
would just mean that every usage of Function1<R,T> is replaced by
Function1<? extends R, ? super T1>. The wildcards are stored in the type
itself. It might not make sense to you to use exactly wildcards in the
type definition this way, but I did not want to introduce a new syntax.

This checks are done by the compiler (due to type erasure). There might
be a better way to express this yet other than that the implementation
could be done. Given that throws had to be added if the BGGA route would
be taken (no?), was there any compelling reason not to consider variance
qulifiers in type declarations? IMHO the big plus is that interface
types are concise again. And the feature could be used in general. I
also see no difference if every type of a function is automatically
translated to have wildcards.

And if I may add wildcards arbitrarily in type declarations I do not
think it is dangerous to declare them generically in the type definition.

Scala takes a similar route and allows variance annotations on generic
types. There are some additional checks such that the type declaring the
annotations must conform to covariance and contravariance. See chapter 4
section 5 of the Scala Language Specification [1].

-- Jakob

[1] -
http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf


More information about the closures-dev mailing list