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 <open...@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>>
