Asking to contribute(?)

[Rob Spoor]

It appears this discussion has died out...

I really think it's a great addition to have a transform method added to 
not just Stream*, but also StringBuilder, StringBuffer and Optional. A 
search for classes containing "Builder" shows the following that could 
also be interesting:

* HttpClient.Builder, HttpRequest.Builder and WebSocket.Builder
* DateTimeFormatterBuilder
* ProcessBuilder


If we don't go for the Transformable interface (which I admit looks iffy 
due to the cast that can fail if a class decides to use a different 
generic type), I think we should at least add a transform method to 
Stream, StringBuilder, StringBuffer and Optional. The other classes I 
mentioned are probably not used as often as these 4, so let's omit them 
to keep the scope of the change limited.


* For the same reasons that OptionalInt, OptionalLong and OptionalDouble 
won't get (extra) map methods, let's skip IntStream, LongStream and 
DoubleStream as well.


On 05/11/2020 06:23, Justin Dekeyser wrote:
> Hello,
> 
> Thank you for your answer, I appreciate!
> 
> Indeed, it is clear to me that if the feature should be a concern of both
> String and Stream (or more?), a common contract can be designed.
> 
> The impl. you sketch is the more natural one I think. (it's also the one I
> gave in the other mailing grap about that toList stuff, so I guess it's ok!)
> 
> I am just a bit cold about the idea that the spec will make the compiler's
> job, but I guess in Java there is no work around.
> 
> I don't know what the community thinks about it.
> 
> Regards,
> 
> Justin Dekeyser
> 
> On Wednesday, November 4, 2020, Rob Spoor <openjdk at icemanx.nl> wrote:
> 
>> On 04/11/2020 14:18, Justin Dekeyser wrote:
>>
>>> Hello everyone,
>>>
>>> I have been following this mailing list for several months, and
>>> earlier today my attention was drawn to
>>> https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been
>>> dreaming of such a feature for a long time now.
>>>
>>> I would really be interested in solving it, but I do not know its
>>> current state nor if someone would agree to sponsor my work on that.
>>>
>>> It would be my very first intervention in the Java code base.
>>> (Still have to make sure the Oracle agreement paper does not conflict
>>> with my current job contract, so nothing's ready for now.)
>>>
>>> Thank you for your time,
>>>
>>> Best regards,
>>>
>>> Justin Dekeyser
>>>
>>>
>> I'd like this feature as well, but why stop at Stream? String already has
>> the transform method, but StringBuilder (and StringBuffer) could also use
>> it.
>>
>> And that's where you're likely to start copy pasting. I've done so for
>> several builder classes I've written for myself. So here's a thought: why
>> add this method to classes, when you can create a trait using an interface
>> with a default method?
>>
>>      public interface Transformable<T> {
>>
>>          default <R> R transform(Function<? super T, ? extends R> f) {
>>              // note: this would need documentation that a class X is
>>              // only allowed to implement Transformable<X>
>>              return f.apply((T) this);
>>          }
>>      }
>>
>> So you could get the following, and each would automatically get the
>> transform method:
>> * public class String implements Transformable<String>
>> * public class StringBuilder implements Transformable<StringBuilder>
>> * public class StringBuffer implements Transformable<StringBuffer>
>> * public interface Stream<T> implements Transformable<Stream<T>>