java.util.stream 'map' method, proposal of method name change

[Brian Goetz]

Naming is a deeply subjective thing; whatever names we chose, invariably 
someone (or many someones) would come along and say "why didn't you 
choose X."  Sometimes there's a good reason why the proposed X is 
clearly worse; sometimes its just a subjective association.  But of 
course, we have to pick one name that is good enough for all Java 
developers, even if it is not ideal from some subjective viewpoints.

Names like `replaceWith` were actually considered, and rejected for a 
good reason:   words like "replace" have a connotation a mutative 
update.  This would be a good fit for in-place mutative methods like 
`List.replaceAll(T -> T)`, but a worse choice for a stream method.  
(You're free to disagree, of course.)

Regardless, changing method names on core abstractions like List or 
Stream is completely out of the question; this would be both a binary- 
and source-incompatible change (existing compiled classfiles would stop 
working; existing sources couldn't be recompiled.)  And adding an alias 
with a different name would be silly, unless the old name were so 
egregiously inappropriate as to be dangerous.




On 8/11/2017 10:36 PM, Krunoslav Magazin wrote:
> Hi. When using java.util.stream 'map' method my opinion is that
> 'replaceWith' as method name would better describe what method do.
> 'map' method is applied on input stream, returns output stream but
> returned stream elements are return values from 'map' method Function
> argument. We continue our work with output stream so mapping with
> input stream have no meaning. Input stream is replaced with output
> stream which elements are outputs of Function. After that point we can
> forgot about input stream.
>
> Example of usage:
> now - stream.map(e -> e+2)..        // read: map input stream with
> output stream containing elements resulting from function (e -> e+2)
> proposed - stream.replaceWith(e -> e+2).. // read: replace input
> stream with output stream containing elements resulting from function
> (e -> e+2)
>
> With 'map' method number of elements is the same but we do not make
> assumptions what passed Function will do (specialization) until the
> moment we pass Function implementation as method argument..
>
> I will appreciate any comments.
> Best regards,
> Krunoslav Magazin