Another appeal to fix Function.compose

[David Holmes]

On 28/03/2013 9:24 PM, Stephen Colebourne wrote:
> This change means there is no way to do the original behaviour. As a
> non-functional Java programmer, I would read f.compse(g) as a
> "function that does f, then does g", ie. as per the original
> behaviour. The new compose behaviour seems entirely backwards (again,
> as a non FP programmer).

I am not a functional programmer. Function composition is something I 
learnt in "freshman" maths, if not high school maths.

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

David
-----

>
> Stephen
>
>
> On 28 March 2013 00:24, Mike Duigou <mike.duigou at oracle.com> wrote:
>> 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
>>>
>>
>>
>