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

[John R Rose]

On Mon, 26 Oct 2020 17:29:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> …`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 … 
}

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

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