Stream reuse in superclass

[Henry Jen]

I don't have the context on what you trying to achieve, so this is probably not apply.

My feeling is that if you can convert to use stream API, perhaps it's more suitable to deal with individual element.

Class Foo {
	process (T element) {…}
        bar(Stream<T> s) {…}
}

Class PowerFoo extends Foo {
	process (T element) {…}
}

The other common idiom would be chaining Stream process,

Class Foo {
	bar (Stream<T> s) {…}
}

Class PowerFoo extends Foo {
	Stream<T> doSomethingWith(Stream<T> s) {…}
	bar (Stream<T> s) {
		return super.bar(doSomethingWith(s));
	}
}

HTH,
Henry


On Apr 4, 2013, at 11:59 PM, Jose <jgetino at telefonica.net> wrote:

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