RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]

[Rémi Forax]

On Mon, 26 Oct 2020 18:01:04 GMT, John R Rose <jrose at openjdk.org> wrote:

>> @rose00 My bad. You're right, I realized we could also use `asType` later on (I did call it out in the CSR), but It's still a bit more wordy than what I'm proposing.
>> 
>> `dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`, I think doing that also begs for adding a `MethodHandle::changeParameterType` (with a single index and varargs overload). But, in that case it seems fair to just point users at `asType` instead.
>> 
>> In other words; `dropReturn` seems fine to get parity with `dropArguments`, but `changeReturnType` seems a step too close to `asType` (also since it implies adding `changeParameterType` as well). So, maybe this RFE is a bust, and users should use `asType` instead? Or do you think adding both `changeReturnType` and `changeParameterType`(s) seems worth it? (I'm not so sure).
>
>> …`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
> 
> That's a very reasonable point.  People might look for `dropRT` after they find `dropAs`.  And `MHs` is designed as a large-ish set of utility methods.
> 
> I agree that adding `MH::changeRT` is a slippery slope; it tends to lift more of the MT API onto MH, and it starts to put new stuff into the smaller MH API; that was my bad.
> 
> But (in the spirit of brainstorming, and agreeing with your present proposal), I'll suggest a separate idea to think about.  Use a HOFP API to give easy access to the entire `MT` API all in one go, by reifying the `MH.type` property as a temporary (lambda argument):
> 
> MethodHandle mapType(MethodHandle mh, UnaryOperator<MethodType> fn) {
>    return mh.asType(fn.apply(mh.type()));
> }
> 
> This also suggests a possible argument transform utility, a sort of mini-version of Charlie Nutter's MH builder API:
> 
> MethodHandle mapArguments(MethodHandle mh, UnaryOperator<List<ArgumentValue<?>>> fn) {
>   var args = mh.type().argumentList().stream().map(t -> makeArg(t)).asList();
>   args = fn.apply(args);
>   … do stuff to re-weave mh with the resulting argument transforms …
> }
> public sealed interface ArgumentValue<T> {
>   Class<T> type();
>   <U> ArgumentValue<U> asType(Class<U> newType);
>   … other stuff for pre-applying MHs … 
> }

instead of mapArguments(), i believe it's better to have a method map on a MethodType that takes two mapping functions, one for the return type and one for the prameter types.

so one can write:
  MHs.mapType(mh, mt -> mt.map(Function.identity(), t-> t.isPrimitive? t: Object.class))
to not change the return type and erase the parameter type to Object if they are not primitives

With that, changing the return type to void can be done that way too
  MHs.mapType(mh, mt -> mt.map(__ -> void.class, Function.identity())

-------------

PR: https://git.openjdk.java.net/jdk/pull/866