Function types versus arrays

[Joshua Bloch]

Neal,

On Wed, Feb 17, 2010 at 3:10 PM, Neal Gafter <neal at gafter.com> wrote:

> On Wed, Feb 17, 2010 at 2:59 PM, Joshua Bloch <jjb at google.com> wrote:
> > I really don't understand this.  Earlier on, Alex said that we should
> > refrain from thinking too hard about the implementation at this point,
> and I
> > still believe that to be true.  If you could show that some interaction
> of
> > the proposed syntax and semantics interacted poorly with the existing
> type
> > system, that would be a big problem, but I haven't seen such an argument
> > that didn't presuppose a particular implementation of function types. I
> > really do think we should design the best spec (syntax and semantics) and
> > then see if it's implementable.
>
> I agree with the process you describe.  I just think we're a couple of
> steps ahead of you.  Setting aside the precise syntax, there is a
> specific problematic interaction of the currently proposed semantics
> with the existing type system, and we're exploring the fallout of that
> issue.  We don't have to wait for the syntax to be settled to explore
> the fallout of the semantics issue, and as I pointed out resolving the
> semantic issue can help guide the syntax.
>

I don't buy this.  All we know is that it requires some effort to implement
reified function types. We always claimed that the reason that we did
generics via erasure was migration compatibility, not ease of
implementation. *We don't have that excuse this time.*

>
> > Earlier, I suggested that we should allow arrays of function types if we
> > can.  \Otherwise, we're damning function types to life as second-class
> > citizens of the Java type system. We're also screwing up variable-arity
> > function typed args, as varargs is a leaky abstraction built atop arrays.
> >  This isn't a theoretical concern; it impacts reasonable programs. For
> > example, consider a method that takes a bunch of #int(int) functions and
> > returns their composition:
> >     #int(int) compose(#int(int)... fns) {  <implementation> }
> > This should definitely be legal, and shouldn't generate a warning
> > (especially given that we're providing a means to eliminate this sort of
> > warning on generic varargs parameters in Java 7).
>
> This is all true, but the facts of the universe we live in have
> conspired against us.  We should if we can, but we can't.


Can't is a strong word.  All we can say is that it would involve VM change.
 It may be worth that.


I should add that Howard relaunched this thread with the idea of

relaxing Java's usual assumption that a subtype conversion preserves

the identity of the reference.  I don't think that relaxation actually

solves the problem, and it does break other things in the language.

But it is worth spending some time determining if and how it breaks.


I do not think this is a good idea. It violates the principle of least
astonishment by sacrificing a fundamental truth of the language ("casting an
object reference to an object reference type does not change its identity).

      Josh