Boxing function types

[Neal Gafter]

Alex-

Java's "convertible" relationship is not transitive: there are conversions
Integer->int->long->Long, but not Integer->Long.  Yet the subtype
relationship must be transitive for type inference and overriding.
Therefore the convertible relationship cannot be used for subtyping.

I agree that this situation is unfortunate.  The jsr201 expert group
considered this, and decided that they prefer things this way.  In their
judgment, it was more important to use the existing classes for boxed types
(rather than interfaces related by inheritance, as Gilad and I proposed).
In the process, they give up the likelihood of ever supporting the
conversions as subtype relations.  One consequence of the decision is that
it is unlikely we will be able to extend generics to work over primitives,
and consequently the kind of API duplication you see in the ParallelArray
framework cannot easily be eliminated.  I suspect some of the jsr201
participants now regret their decision, but it is too late to change it.

Cheers,
Neal

2009/11/25 Kochurov Alexander <ipris at inbox.ru>

> Neal,
>
>    I reexamined my idea and want to highlight some reasons why is it
> usefull:
> 1) boxing function types allows you to change implementation details
> without breaking any code (e.g. if you need to replace collection of boxed
> primitives with array or Trove4j primitive collections for performance
> reasons you can just replace field/argument declatations and all closures
> would still be valid);
> 2) users of your API needn't to know a reason why you require their
> closures to return @NotNull Integer instead of int, but there is also no
> need to write #(Integer i) Integer.valueOf(someClosure.invoke(i.intValue()))
> every time for #int(int) someClosure reseived from user;
> 3) it's a generalisation of boxing concept; enchanced for-loop allows you
> to use implicit boxing/unboxing for loop variable, why closures don't? (for
> (int i: Arrays.asList(1, 2, 3)) does unboxing each iteration)
> 4) ...
> 5) PROFIT!
>    Yes, it brings some flaws and performance drawbacks, but almost any
> syntactic sugar does.
>    (moreover, IMHO java should allow methods with primitive arguments to
> override methods with boxed arguments, e.g. int method(int x) should
> override Integer method(Integer x) )
>
> Thanks for your feedback,
> Alex
>
> -----Original Message-----
> From: Neal Gafter <neal at gafter.com>
> To: Kochurov Alexander <ipris at inbox.ru>
> Date: Tue, 24 Nov 2009 08:47:31 -0800
> Subject: Re: Boxing function types
>
> > On Sun, Nov 22, 2009 at 8:25 AM, Neal Gafter <neal at gafter.com> wrote:
> >
> > > This is an interesting idea, but you have the variance backwards for
> > > argument types.  The argument types in the function on the
> right-hand-side
> > > of the assignment must be subtypes (not supertypes) of the argument
> types in
> > > the function on the left-hand-side.
> > >
> >
> > How embarrassing.  You had it right the first time.
> >
> > Cheers,
> > Neal
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091125/3ba7bd94/attachment.html