[mvt] RFR MVTTest refactor

[Paul Sandoz]

http://cr.openjdk.java.net/~psandoz/valhalla/mvt-test/webrev/test/valhalla/mvt/MVTTest.java.sdiff.html <http://cr.openjdk.java.net/~psandoz/valhalla/mvt-test/webrev/test/valhalla/mvt/MVTTest.java.sdiff.html>

Also includes a test with a counted loop (although i have yet to look at how that behaves regarding LFs).

Paul.

> On 2 Jun 2017, at 15:54, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 
> 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.
>>>>> 
>>>> Yeah:
>>>> 
>>>>   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.
> 
> Maurizio
> 
> 
>> 
>> Paul.
>