Another appeal to fix Function.compose

[Ted Neward]

+1 to the idea of having both, with recognizable names ("compose" and
"andThen" seem to fit the bill) and semantics clearly spelled out in docs.

Otherise, this is the first thing that everybody will write for themselves
and (time to pull out the Nuclear Option of Linguistic Persuasion) it will
feel like C++'s missing string type all over again. ;-)

Ted Neward
Leading, Speaking, Consulting, Writing
http://www.tedneward.com

> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-
> bounces at openjdk.java.net] On Behalf Of Jed Wesley-Smith
> Sent: Thursday, March 28, 2013 6:02 PM
> To: Stephen Colebourne
> Cc: lambda-dev
> Subject: Re: Another appeal to fix Function.compose
> 
> The old combinator is often known as "andThen" -  f.andThen(g) is
> equivalent to g.compose(f).
> 
> I think having both is reasonable and possibly ideal.
> 
> On 28 March 2013 22:24, Stephen Colebourne <scolebourne at joda.org>
> 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 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).
> >
> > 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/s
> >>> hare/classes/java/util/function/Function.java
> >>>
> >>
> >>
> >