Re[4]: Boxing function types

[Кочуров Александр]

Neal,
     I didn't take that into account.
     But boxing conversions Integer -> int -> Integer, Long -> long -> Long, etc are still transitive and therefore could be used as covariant return types and contravariant argument types.


-----Original Message-----
From: Neal Gafter <neal at gafter.com>
To: Kochurov Alexander <ipris at inbox.ru>
Date: Wed, 25 Nov 2009 00:35:45 -0800
Subject: Re: Re[2]: Boxing function types

> 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
> > >
> > >
> >
> 
>