Boxing function types

[Reinier Zwitserloot]

That seems like a good idea, Kochurov.

Speaking of autoboxing and closures, Mark Reinhold showed a slide containing
all the types in Parallel Array, basically using the explosion of these as
one of the main reasons why we need structural types with our closures.

Presumably boxing and autoboxing don't need to access memory, and, thus,
probably have an insignificant (not to mention probably entirely removable
via JIT) performance cost associated with them. Has anyone checked what
happens when you cut down jsr166z's types by only have the generic variant?
So, Instead of:

Ops.LongMaxReducer,

just stick with:

Ops.MaxReducer<Long>,

and instead of:

ParallelDoubleArray

just go with:

ParallelArray<Double>

Another point I'm noticing when looking through PA's classes is that a lot
of suggested duplication is unfair reasoning. For example, PA has separate
interfaces for MinReducer and MaxReducer. They are both SAMs with the same
signature on the one method. Clearly the design of PA fundamentally
disagrees with the notion that, for situations where closures work better,
giving the types of the closures a name and a place for javadoc is not
useful. This argument is espoused by many BGGA fans, for example here:

http://weblogs.java.net/blog/brucechapman/archive/2008/02/bgga_fud_bustin.html


Between PA's design aesthetic, and (hopefully) the ability to cut down PA's
typeset to less than half of what it has now by getting rid of the primitive
versions and relying on generics parameters instead, it seems target-typing
closures to a named type instead of introducing structural types should be
considered.

--Reinier Zwitserloot




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

> Gentlemens,
>
> what about introducing boxing/unboxing for functional types?
>
> As Java generics don't allow us to use primitive types as type parameters,
> all java implementations of collection algorithms (such as map, fold,
> filter, etc.) would possibly use wrapper types such as Integer, Float and
> function types with wrapper arguments.
>
> So it would be great if every function type with argument types A[1],
> A[2],.. A[n] and result type Ra may be implicitly boxed into any other
> function type with argument types B[1], B[2], .. B[n] and result type Rb if
> either A[i] = B[i] or A[i] can be converted into B[i] using implicit
> convertion for any i = 1..n and if it's result type Ra either matches Rb or
> may be converted implicitly.
> (So I mean not only boxing/unboxing but also widening convertions for
> primitive types, e.g. function with result of short may be converted
> implicitly into function which returns int, long, float, double, Short,
> Integer, Long, Float, Double but not byte, Byte, etc.)
>
> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091122/b9701eae/attachment.html