On Mon, 26 Oct 2020 17:29:11 GMT, Jorn Vernee <jver...@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
