java.util.stream 'map' method, proposal of method name change
brian.goetz at oracle.com
Tue Aug 15 20:04:55 UTC 2017
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
More information about the core-libs-dev