creation of ReadWriteStream with #on:
Locked
 
|
Hi,
ReadWriteStream inherits from WriteStream which hinerits from PositionableStream. When you create a ReadWriteStream with #on: you use the default definition in PositionableStream : PositionableStream class >> on: aCollection "Answer an instance of me, streaming over the elements of aCollection."
^self basicNew on: aCollection #on: is not overriden in the instance side of ReadWriteStream and therefore it's the definition of WriteStream that is called :
WriteStream >> on: aCollection super on: aCollection. readLimit := 0.
writeLimit := aCollection size. Put the readLimit at 0 make sense for a WriteStream ( with witch your not supposed to read ) but when you create a ReadWriteStream on a collection you would be able to read what is already in the collection, no?
I wonder why #on: has not been overriden in the instance side of ReadWriteStream ? Maybe it's not a good idea to create a ReadWriteStream with a collection that already includes elements ? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: creation of ReadWriteStream with #on:
|
|
> Put the readLimit at 0 make sense for a WriteStream ( with witch
> your not supposed to read ) but when you create a ReadWriteStream on > a collection you would be able to read what is already in the > collection, no? > I wonder why #on: has not been overriden in the instance side of > ReadWriteStream ? > Maybe it's not a good idea to create a ReadWriteStream with a > collection that already includes elements ? It looks like on: must be overridden in ReadWriteStream. With ReadStream I have: (ReadStream on: (1 to: 20)) next => 1 (ReadStream on: (1 to: 20)) next; next => 2 However, with ReadWriteStream, nil is returned, for the very problem you mentioned: (ReadWriteStream on: (1 to: 20)) next => nil If I cut and paste PositionnableStream>>on: in ReadWriteStream, then I have the behavior I expected: (ReadWriteStream on: (1 to: 20)) next => 1 (ReadWriteStream on: (1 to: 20)) next; next => 2 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: creation of ReadWriteStream with #on:
|
|
You haven't set the writeLimit by just copying PositionableStream
though, have you? Perhaps: ReadWriteStream >> on: aCollection super on: aCollection. readLimit := aCollection size. would be a better idea? Intervals can't be stored into by the way, so using a RWStream on one doesn't make much sense ;) here's a more accurate example for RWStream: rws := ReadWriteStream on: (1 to: 20) asArray. [rws atEnd] whileFalse: [rws peek odd ifFalse: [rws nextPut: 0] ifTrue: [rws next]] And the collection will contain #(1 0 3 0 5 0 7 0 9 0 11 0 13 0 15 0 17 0 19 0), as expected. Cheers, Henry On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: >> Put the readLimit at 0 make sense for a WriteStream ( with witch >> your not supposed to read ) but when you create a ReadWriteStream on >> a collection you would be able to read what is already in the >> collection, no? >> I wonder why #on: has not been overriden in the instance side of >> ReadWriteStream ? >> Maybe it's not a good idea to create a ReadWriteStream with a >> collection that already includes elements ? > > > It looks like on: must be overridden in ReadWriteStream. > With ReadStream I have: > (ReadStream on: (1 to: 20)) next => 1 > (ReadStream on: (1 to: 20)) next; next => 2 > > However, with ReadWriteStream, nil is returned, for the very problem > you mentioned: > (ReadWriteStream on: (1 to: 20)) next => nil > > If I cut and paste PositionnableStream>>on: in ReadWriteStream, then I > have the behavior I expected: > (ReadWriteStream on: (1 to: 20)) next => 1 > (ReadWriteStream on: (1 to: 20)) next; next => 2 > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: creation of ReadWriteStream with #on:
|
|
> You haven't set the writeLimit by just copying PositionableStream
> though, have you? I suggested to copy PositionableStream>>on: in ReadWriteStream: on: aCollection collection := aCollection. readLimit := aCollection size. position := 0. self reset Your implementation works well too, it has no duplication, but has a dependency over the implementation of the superclass. Cheers, Alexandre > > > > On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: > >>> Put the readLimit at 0 make sense for a WriteStream ( with witch >>> your not supposed to read ) but when you create a ReadWriteStream on >>> a collection you would be able to read what is already in the >>> collection, no? >>> I wonder why #on: has not been overriden in the instance side of >>> ReadWriteStream ? >>> Maybe it's not a good idea to create a ReadWriteStream with a >>> collection that already includes elements ? >> >> >> It looks like on: must be overridden in ReadWriteStream. >> With ReadStream I have: >> (ReadStream on: (1 to: 20)) next => 1 >> (ReadStream on: (1 to: 20)) next; next => 2 >> >> However, with ReadWriteStream, nil is returned, for the very problem >> you mentioned: >> (ReadWriteStream on: (1 to: 20)) next => nil >> >> If I cut and paste PositionnableStream>>on: in ReadWriteStream, >> then I >> have the behavior I expected: >> (ReadWriteStream on: (1 to: 20)) next => 1 >> (ReadWriteStream on: (1 to: 20)) next; next => 2 >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: creation of ReadWriteStream with #on:
|
|
Well, my point was that by copying that, you don't set writeLimit, so
attempting to write to the ReadWriteStream results in an error... (which is why I gave a test that both reads and writes instead of just reading) In that case, what's the point? It's functionality is then just the same as a ReadStream. (Which is doubly confusing, seeing as it inherits from WriteStream) so doing it your way, we'd have to do: on: aCollection readLimit := aCollection size. writeLimit := aCollection size. position := 0. self reset. instead of a straight copy. Btw, your version has a dependency on the super as well, mainly that it defines the correct instvars. :) Which version to prefer comes down to taste, I guess. Cheers, Henry On Jun 30, 2009, at 3:54 35PM, Alexandre Bergel wrote: >> You haven't set the writeLimit by just copying PositionableStream >> though, have you? > > I suggested to copy PositionableStream>>on: in ReadWriteStream: > on: aCollection > > collection := aCollection. > readLimit := aCollection size. > position := 0. > self reset > > Your implementation works well too, it has no duplication, but has a > dependency over the implementation of the superclass. > > Cheers, > Alexandre > > >> >> >> >> On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: >> >>>> Put the readLimit at 0 make sense for a WriteStream ( with witch >>>> your not supposed to read ) but when you create a ReadWriteStream >>>> on >>>> a collection you would be able to read what is already in the >>>> collection, no? >>>> I wonder why #on: has not been overriden in the instance side of >>>> ReadWriteStream ? >>>> Maybe it's not a good idea to create a ReadWriteStream with a >>>> collection that already includes elements ? >>> >>> >>> It looks like on: must be overridden in ReadWriteStream. >>> With ReadStream I have: >>> (ReadStream on: (1 to: 20)) next => 1 >>> (ReadStream on: (1 to: 20)) next; next => 2 >>> >>> However, with ReadWriteStream, nil is returned, for the very problem >>> you mentioned: >>> (ReadWriteStream on: (1 to: 20)) next => nil >>> >>> If I cut and paste PositionnableStream>>on: in ReadWriteStream, >>> then I >>> have the behavior I expected: >>> (ReadWriteStream on: (1 to: 20)) next => 1 >>> (ReadWriteStream on: (1 to: 20)) next; next => 2 >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
With both of your answers I understand that there was a problem and apparently no good reason to have a ReadLimit set at 0.
That was my question, thank you :) (anyway this problem should disapear when Nile will replace the actual Stream hierarchy ;))
2009/6/30 Henrik Johansen <[hidden email]> Well, my point was that by copying that, you don't set writeLimit, so _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: creation of ReadWriteStream with #on:
|
|
Hi Cyrille,
2009/6/30 Cyrille Delaunay <[hidden email]>: > With both of your answers I understand that there was a problem and > apparently no good reason to have a ReadLimit set at 0. > That was my question, thank you :) > (anyway this problem should disapear when Nile will replace the actual > Stream hierarchy ;)) there are a lot of oddities in the stream hierarchy. You probably don't want to fix them manually, it requires a complete rewrite. Bye -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: creation of ReadWriteStream with #on:
|
|
In reply to this post by Henrik Sperre Johansen
Redefining on: on ReadWriteStream generate an error when I save with
Monticello. I haven't got the time to dig into this however. Cheers, Alexandre On 30 Jun 2009, at 16:21, Henrik Johansen wrote: > Well, my point was that by copying that, you don't set writeLimit, so > attempting to write to the ReadWriteStream results in an error... > (which is why I gave a test that both reads and writes instead of just > reading) > In that case, what's the point? It's functionality is then just the > same as a ReadStream. (Which is doubly confusing, seeing as it > inherits from WriteStream) > > so doing it your way, we'd have to do: > > on: aCollection > readLimit := aCollection size. > writeLimit := aCollection size. > position := 0. > self reset. > > instead of a straight copy. > > Btw, your version has a dependency on the super as well, mainly that > it defines the correct instvars. :) > Which version to prefer comes down to taste, I guess. > > Cheers, > Henry > > On Jun 30, 2009, at 3:54 35PM, Alexandre Bergel wrote: > >>> You haven't set the writeLimit by just copying PositionableStream >>> though, have you? >> >> I suggested to copy PositionableStream>>on: in ReadWriteStream: >> on: aCollection >> >> collection := aCollection. >> readLimit := aCollection size. >> position := 0. >> self reset >> >> Your implementation works well too, it has no duplication, but has a >> dependency over the implementation of the superclass. >> >> Cheers, >> Alexandre >> >> >>> >>> >>> >>> On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: >>> >>>>> Put the readLimit at 0 make sense for a WriteStream ( with witch >>>>> your not supposed to read ) but when you create a ReadWriteStream >>>>> on >>>>> a collection you would be able to read what is already in the >>>>> collection, no? >>>>> I wonder why #on: has not been overriden in the instance side of >>>>> ReadWriteStream ? >>>>> Maybe it's not a good idea to create a ReadWriteStream with a >>>>> collection that already includes elements ? >>>> >>>> >>>> It looks like on: must be overridden in ReadWriteStream. >>>> With ReadStream I have: >>>> (ReadStream on: (1 to: 20)) next => 1 >>>> (ReadStream on: (1 to: 20)) next; next => 2 >>>> >>>> However, with ReadWriteStream, nil is returned, for the very >>>> problem >>>> you mentioned: >>>> (ReadWriteStream on: (1 to: 20)) next => nil >>>> >>>> If I cut and paste PositionnableStream>>on: in ReadWriteStream, >>>> then I >>>> have the behavior I expected: >>>> (ReadWriteStream on: (1 to: 20)) next => 1 >>>> (ReadWriteStream on: (1 to: 20)) next; next => 2 >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |