Another appeal to fix Function.compose

[Mike Duigou]

Fixed. 

http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fa66ee11db44

Sorry for the delay. There was no great debate just many, many fish to be fried.

To those already using Function.compose()--we apologize in advance for breaking your code with this change.

Mike

On Mar 26 2013, at 04:52 , Jed Wesley-Smith wrote:

> 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
>