Thank you for following up - we all know the core-libs team has a busy workload, and naming topics are always tricky.
I'm personally unconvinced that `transform()` is the best name out there. While transform is OK for String and maybe Optional, it is poor for List and Stream. In addition, I'm still not overly convinced that this is an appropriate stylistic direction for Java to go more generally (though I fully agree with point #2 on language change below). However, since the core-libs team is clearly indicating a desire to close the topic, I have no personal intention of objecting further.. thanks Stephen On Tue, 4 Dec 2018 at 18:38, Stuart Marks <stuart.ma...@oracle.com> wrote: > Hi everybody, > > I've finally caught up with all of this. I see that several people are > surprised > by the way this has turned out. As the first-named reviewer on this > changeset, I > felt I should try to figure out what happened. > > While this API point stands on its own, this is really part of Jim's RSL > work > [1] which includes several API additions to String, and which will likely > have a > significant effect on how String literals are used in Java code. > > Jim started code review [2] and CSR review [3] for this proposal back in > September. There was a gap of several weeks, followed by a revised > proposal on > 12 Nov [4][5] that changed the method's name from "transform" to "map". > > There was further discussion over the next couple days; in particular > there were > some objections to the method name "map". On 26 Nov Jim pushed the > changeset > with the name changed back to "transform". > > From reading just the messages on the mailing list, I can certainly see > why > people were surprised. It looked like there was an issue open for > discussion, > yet Jim went ahead and pushed the revised change anyway. What happened? > > Given that the primary open issue was about naming, and such mailing list > discussions can go on for an arbitrarily long time, Jim asked Brian > off-list for > a decision on this. The results were: > > 1) the name for this method on String should be "transform"; > > 2) adding library methods is a reasonable way for the platform to provide > this > capability (as opposed to various language enhancements that might be > contemplated); and > > 3) the intent is to colonize the name "transform" for this operation on > this and > other classes, such as List, Optional, etc. (It may well be the case that > there > is no name that is a good fit for both Stream and for everything else, > given > Stream's highly stylized API; we can consider the tradeoffs between > consistency > and clarity when we get to that particular one.) > > The primary thing that went wrong here was that Brian and Jim neglected to > circle back to the list to record this decision. This was an oversight. > > There could and should have been better communication about this. Brian, > Jim, or > I should have documented the results of this decision and followed up on > the > mailing list. None of us did. Sorry about that. > > What else should be done here? > > One thing is that we (I) can make a better effort to keep up on emails, > though > the volume -- on a wide variety of topics -- is significant. > > Another point is that issues that are raised on the mailing list are often > discussed and resolved off the mailing list. While we make significant and > ongoing efforts to write up relevant offline discussions for public > consumption > (see, for example, see the recent writeup on nullable values [6]), > sometimes > things will fall through the cracks. > > Finally, we should also record that this particular decision sets a > precedent > for the use of the name "transform" for methods that do similar things on > other > classes. To this end, I've updated this bug with a note about "transform": > > JDK-8140283 [7] add method to Stream that facilitates fluent chaining > of > other methods > > and I've also filed the following RFE: > > JDK-8214753 [8] (opt) add Optional::transform, allowing an arbitrary > operation on an Optional > > s'marks > > [1] http://openjdk.java.net/jeps/326 > > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055532.html > > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055533.html > > [4] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html > > [5] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html > > [6] > > http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html > > [7] https://bugs.openjdk.java.net/browse/JDK-8140283 > > [8] https://bugs.openjdk.java.net/browse/JDK-8214753 > >
