Stream reuse in superclass

Jose jgetino at telefonica.net
Thu Apr 4 23:59:18 PDT 2013


Well, the first step in introducing streams in my existing code was to use
conversions 

       Collection--> Stream -->Collection

inside the body of existing methods, to take advantage of the stream
operations. This step leaded to a significant simplification of many
procedures. 

Next step was to wonder, do really I need these collections?. Then I found
methods in my code that would admit replacing collections with streams in
their signature, leading again to a simplification of the code, because it
saved many conversions. 

This procedure is what I mean for adapting old code to the streams
framework. I found it a natural way to experiment with streams, 
because you already has the code and knows how it is expected to perform. 

And it was a smooth path until the case that generated this thread. 
The rule that I submited to your consideration would correspond to the
second step of this path: refactoring method signatures.  



  
 



-----Mensaje original-----
De: David Holmes [mailto:david.holmes at oracle.com] 
Enviado el: viernes, 05 de abril de 2013 7:30
Para: Jose
CC: lambda-dev at openjdk.java.net
Asunto: Re: Stream reuse in superclass

On 5/04/2013 3:22 PM, Jose wrote:
> So, if I understood you, a rule to adapt old code based on Collections to
> the new paradigm would be something like:
>
> "try to produce streams instead of collections when possible, but keep on
> consuming collections"

I'm not sure what that means.

The Stream-based API is a completely different mindset to operating 
directly on Collections. I'm not sure there is a "rule" to "adapt".

David

>
>
>
> -----Mensaje original-----
> De: David Holmes [mailto:david.holmes at oracle.com]
> Enviado el: viernes, 05 de abril de 2013 3:31
> Para: Jose
> CC: lambda-dev at openjdk.java.net
> Asunto: Re: Stream reuse in superclass
>
> On 5/04/2013 6:59 AM, Jose wrote:
>> I have a class that contains a method that consumes a Stream (previously
> was
>> a Collection)
>
> And that is your problem. You can not think of operations on a stream
> the way you would a collection, as a stream is not a collection. Your
> class that operated on the elements of the collection would now become
> an operation to be passed to a suitable stream method to be applied to
> each element.
>
> David
>
>> Class Foo<T>{
>> 	   bar(Stream<T> s){
>>                         .........
>> 	}
>> }
>>
>>
>> This method is overriden in a subclass, that first consumes the stream
and
>> then calls super
>>
>> Class PowerFoo<T> extends Foo<T>{
>>      	bar(Stream<T> s){
>>        		doImportantThingsWidth(s);
>> 		//now the stream is consumed  :-(
>>        		super.bar(s)
>> 	}
>> }
>>
>>
>> What is the recomended way to handle situations like this?.
>>
>> Curently I'm collecting the stream into a list and getting two streams
> from
>> it.
>>
>>
>



More information about the lambda-dev mailing list