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

Jorn Vernee jvernee at openjdk.java.net
Fri Oct 30 14:32:01 UTC 2020


On Tue, 27 Oct 2020 10:40:40 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 … 
>> }
>
> It's an interesting idea. It turns something like:
> 
> target = target.asType(target.type().changeReturnType(void.class));
> 
> Into 
> 
> target = target.asType(mt -> mt.changeReturnType(void.class));
> 
> I.e. it removes the need to reference the target handle/type twice, which prevents them from potentially going out of sync (which seems more likely when you have multiple MethodTypes and MethodHandles flying around). Also, it feels unnecessary that, I have to re-specify `target`'s type as a base, when I'm asking `target` to change it's type. This also solves that.

CSR is now provisional. Please review: https://bugs.openjdk.java.net/browse/JDK-8255398

Thanks.

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

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


More information about the core-libs-dev mailing list