Asking to contribute(?)
Justin Dekeyser
justin.dekeyser at gmail.com
Thu Nov 5 05:23:10 UTC 2020
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>>
>
More information about the core-libs-dev
mailing list