Re[2]: Boxing function types

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

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