Function types versus arrays (reification using interface injection)

[Neal Gafter]

On Mon, Feb 8, 2010 at 3:05 PM, Peter Levart <peter.levart at gmail.com> wrote:
> If you implement function types as interfaces, then function types that take just primitive
> parameters and have primitive return type are already reified aren't they?

Not necessarily, because function types also have exception
signatures, and must obey subtype relations that respect them.

> When a function type takes a reference type parameter and/or has a reference return type, then
> some proposals represented it as a generic interface which is represented in run-time as an
> interface with erased parameter/return types - such function type is not reified.
>
> Why not treat function types with reference type parameters and/or return type the same as
> function types with primitive only parameters and return type? Because of sub-type relationships
> among function types?

No, because it doesn't work for code in generic methods, which must be
compiled to use particular classes.

> Then the javac compiler could, for the lambda expression above, generate a class that would
> implement interface FuncObjectToString:

You can't have code that is required to execute when a subtype
relation is involved, because that doesn't interact properly with
subtype relations involving wildcards.  Specifically, a value of type
X<? extends A> should be a subtype of X<? extends B> whenever A is a
subtype of B.  Your translation scheme doesn't provide any way to make
that happen when A and B are related (but not the same) function
types.

> Is this to lunatic? Am I missing a bunch of problems possible with this approach?

Howard Lovatt has proposed something essentially similar, and patched
his proposal every time I asked him how some particular example would
work.  Nothing like this could possibly be considered unless the
scheme has been proven to result in no holes in the type system.  I
haven't yet seen any attempt at a proof for a scheme like this.