[Pharo-project] creation of ReadWriteStream with #on:
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 ?
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <henrik.s.johansen@veloxit.no>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Cyrille, 2009/6/30 Cyrille Delaunay <cy.delaunay@gmail.com>:
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (4)
-
Alexandre Bergel -
Cyrille Delaunay -
Damien Cassou -
Henrik Johansen