On Mon, 26 Oct 2020 18:01:04 GMT, John R Rose <jr...@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
