Another appeal to fix Function.compose

[Jed Wesley-Smith]

Well – to be truly pedantic – I believe this difference is actually
purely syntactic; the difference being simply that the compiler can't
infer the input type for target function. Include the type ascription
and all is well.

Syntactic differences do make for significant usability differences
though, and as you say, this does make a reasonable justification for
the inclusion of both forms.

cheers,
jed.

On 30 March 2013 05:26, Dan Smith <daniel.smith at oracle.com> wrote:
> On Mar 28, 2013, at 5:49 AM, David Holmes <David.Holmes at oracle.com> wrote:
>
>>> I don't mind this change, so long as there is an equivalent that does
>>> the original behaviour that I would see as more natural (again, as a
>>> non FP programmer).
>>
>> Isn't the original behaviour now g.compose(f) ?
>
> Keep in mind that the difference in your translation from 'f.andThen(g)' to 'g.compose(f)' is more than syntactic -- different typing rules apply to the receiver of a method invocation vs. an argument to an invocation.  So both methods are probably justified.
>
> void test(Function<Integer, String> f) {
>   Function<Integer, Integer> f2 = f.andThen(s -> s.length());
>   ...
> }
>
> vs.
>
> void test(Function<Integer, String> f) {
>   // this won't compile: Function<Integer, Integer> f2 = (s -> s.length()).compose(f);
>   Function<Integer, Integer> f2 = ((Function<Integer, String>) s -> s.length()).compose(f);
>   ...
> }
>
> Of course, similar use cases could be constructed going in the opposite direction.  It does seem that it's equally reasonable to want to "chain" a function onto another either beforehand ('compose') or after ('andThen').
>
> —Dan
>