[mvt] RFR - add support for q-types in lambda forms
maurizio.cimadamore at oracle.com
Fri Jun 2 22:54:59 UTC 2017
On 02/06/17 18:50, Paul Sandoz wrote:
>> On 2 Jun 2017, at 10:27, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>> But the other flip of the coin is to handle APIs - if you have a method handle that takes a Q-type, how do you 'bind' its argument? The APIs we have today are boxy. Some of these APIs are used internally by some of the BMH classes, so you could hit them through combinators too.
>>> public MethodHandle bindTo(Object x)
>>> Do we need something like:
>>> public MethodHandle bindToValue (__Value v)
>>> Such a bifurcation is somewhat awkward.
>> Yep - it does look odd.
>> The current working theory is that BMH should work (but will add boxing via asType adaptation) - so, in terms of capabilities, we should be there already.
>> When the time comes, I think we should look at some of the complex combinators (I'm looking at you for loop :-)) and see whether intermediate boxing causes excessive penalty there.
> A start would be to add a simple loop test traversing over an array of Point reducing to one resulting Point. I can add something to the MVTTest, and perhaps refactor into more clearly separated tests of functionality.
That'd be great - thanks! MVTTest is an hacky smoke test I've written to
validate all the features of ValueType MHs. As such is by no means
complete - it'd be great to have more stuff added to it, or to break it
up by functionality as you proposed.
More information about the valhalla-dev