Boxing function types

[Howard Lovatt]

I was a little surprised to see ParallelArray used as the poster child for
function types (structural typing). Having used the library a little I can't
see that function types would make much of a difference (note I am not
saying that shorter inner class/closure syntax wouldn't make a difference).
Having the JavaDoc for the different op types is useful and it also helps
the IDE. Also I don't think you will be able to replace the primitive
versions with generic versions, hence the saving of interface number will
not be that dramatic. The primitive version, ParallelDoubleArray, is
struggling already to show speedup on the code I am trying, so I find it
hard to imagine that the boxing version will fair well.

Why not introduce something close to CISE and see if we really need all the
extra stuff. I think the big drive is for shorter syntax for inner classes
and for some internal iterators on lists, perhaps write access to captured
variables. So long as we don't preclude adding the other stuff at a latter
date; I think it is best to be cautious. Generics were basically a good idea
that got out of hand and made too radical a change (variance) - lets not
make the same mistake again.

As an aside. The code I am porting is a reasonably standard parallel
benchmark used in weather prediction/climate modeling circles for selecting
parallel Fortran compilers and parallel hardware. The code is a finite
difference calculation, a common calculation type for weather/climate. This
benchmark, amongst others, was used by the company I work for to buy a share
in new supercomputer recently (they chose a Sun machine -
http://www.smh.com.au/technology/sci-tech/australias-new-supercomputer-outflops-the-lot-20091116-ihew.html).
I was not part of the decision process, which was joint across a number of
organizations, so I can't say how influential the benchmark was, other than
it is one that the selection group within my company quite like.

 -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091123/a4ce6b12/attachment.html