Another appeal to fix Function.compose

[Jed Wesley-Smith]

Previously I have appealed to the lambda-dev community to fix the
semantics of the Function::compose method to fall into line with all
other languages and mathematic's general understanding of function
composition.

In most languages, and in most maths texts, function composition is
presented as:

f . g

or

f composed with g

where function composition is the application of one function to the
results of another.

In other words, the semantics of composition of f and g is:

f(g(_)) or: f applied to the result of g applied to the argument.

As it currently stands, f.compose(g)* has the opposite semantics; it
says that the f will be applied first _and then_ g will be applied,
ie:

g(f(_)) or: g applied to the result of f applied to the argument.

There is a perfectly good name for this combinator: andThen.

While I totally understand why to the OO developer "f compose g" may
feel like g(f(_)) or f.andThen(g), there is a significant prior work
that defines it the other way. To go against that is merely arbitrary
and contrariwise.

So, my belated appeal is to fall in line with the standard definition
of compose, or to rename the current combinator andThen.

cheers,
jed.

* http://hg.openjdk.java.net/lambda/lambda/jdk/file/112b2a64495a/src/share/classes/java/util/function/Function.java