> An argument against re-using the name map() for this String method is that > Stream.map() and Optional.map() act on the element(s) of the "container" the > method is invoked upon, and return the same raw part of type with type > parameter adjusted, while String.map() would be passing the target object > itself to the function and returning an arbitrary type.
This is exactly why we did not choose the name map() when this feature was proposed. (Such is life when a platform is accrete-only; you have to live with your past decisions, good and bad.) (I didn’t see the proposal to rename transform() to map() fly by; I would have made the same comments as Peter.) > Other languages have introduced an operator to solve that issue (function > call syntax is not fluent) like by example the operator '|>' as in "foo" |> > Utils.capitalizeFirstLetter. Yes, we know :) But we don’t have any current plans to do that, nor use-site extension methods, nor does it seem likely to come to the top of the language priority list very soon. So its not a choice between |> and .transform(); it’s a choice between transform() and nothing. Picking transform() seems pretty good here. Stephen raised the issue of a “broader context”; indeed, the intention of adding a transform() method here was that it would be feasible to add to other types for which it was suitable. String is an obvious candidate for “do it first”, but this is within a broader context.
