Hmm, thanks for the reminder; unfortunately I did not pay close attention to the progress of amber and don't know about the details. I might ask Amber folks in private and share if we have a roadmap for this feature. ________________________________ From: David Alayachew <[email protected]> Sent: Saturday, April 26, 2025 3:22 PM To: Chen Liang <[email protected]> Cc: Nir Lisker <[email protected]>; [email protected] <[email protected]>; amber-dev <[email protected]> Subject: [External] : Re: Casting gatherer
Didn't Brian or one of the Amber folks say that we might (some time in the near future) get a .match() method on streams, which can take in a pattern? It's the pattern version of .map(). On Sat, Apr 26, 2025 at 3:13 PM Chen Liang <[email protected]<mailto:[email protected]>> wrote: Hi Nir, I think currently the most similar code pattern in stream that enjoys a good performance is: .<MyClass>mapMulti((x, sink) -> { if (x instanceof MyClass myClass) { sink.accept(myClass); } }) From the language point of view, such pattern-match-and-map-0/1 operations may be common. That said, can we provide a language feature in the future to convert a pattern declaration to BiConsumer<T, XxxConsumer<args>>? I believe that is a better way to address the question you have raised here. Regards, Chen Liang ________________________________ From: core-libs-dev <[email protected]<mailto:[email protected]>> on behalf of Nir Lisker <[email protected]<mailto:[email protected]>> Sent: Saturday, April 26, 2025 1:55 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Casting gatherer Hi, instanceof has been refitted to include an auto-cast ("pattern matching on instanceof"). Unfortunately, doing this as an intermediate operation on a stream requires first to filter via instanceof and then map via a cast. This is because x instanceof MyClass myClass returns a boolean, not myClass. I've asked for an easier way of doing it long ago directly on Stream and was declined, but now with Gatherers I'm bringing this up again. I think it would be reasonable to put such an operation in the Gatherers class. I imagine that many Gatherer libraries, or utility classes, will include it since it's a common operation, and having it in the JDK means that it'll be done the best way possible (you can optimize where others can't, if applicable here). -- Nir
