ReadWriteStream Issues

Anthony Adachi adachipro at yahoo.com
Mon May 5 21:45:57 UTC 2003


Bert Mayo wrote:

>  Small World!! I've been reading the same book and
ran into the same
>  problem just a few days ago. 

Indeed it is. 

>  The problem seems to come about because
>  ReadWriteStream inherits the "on:" method from
WriteStream, where it
>  is:
>  
>  on: aCollection
>  
>  super on: aCollection.
>  readLimit := 0.
>  writeLimit := aCollection size
>  
>  This sets readLimit to 0 so that in the "next"
method the test
>  "position >= readLimit" is true and the method
returns nil. 

I noticed that when I stepped through the code.
However, I wasn't sure that was the intended behaviour
by whom ever wrote/modified that method or whether it
was a bug.

>  My quick
>  and dirty fix for this was to define a new "on:"
directly in
>  ReadWriteStream class as:
>  
>  on: aCollection
>  
>  super on: aCollection.
>  writeLimit := aCollection size.
>  readLimit := writeLimit.
>  
>  I say "quick and dirty". Perhaps there is a
standard methodology for
>  checking if changing a pre-defined method causes
unwanted interactions
>  within the system, but I haven't gotten to that
part yet in my study of
>  Smalltalk. In any case this does make the examples
on p. 174 - 175
>  work as printed (almost as printed -- there may be
a non-parallelism
>  issue with "nextPut:").

Myself, I'm reluctant to do that, since as you
mention, there may be unwanted interactions. I'm
likely to forget I've made that change and won't
remember making it if a problem does arise as a
result. In that event, I know will be completely
mystified as to the source of the problem (my fixes).
I'm not an very experienced programmer so I don't want
to deal with those kinds of headaches on top of trying
to learn Squeak  Unless, whomever wrote/modified the
ReadWriteStream class attests to the current behaviour
as being a "bug" instead of a "feature". Then I would
feel more confident "fixing" the issue.

Which leads to your statement, "...standard
methodology for checking...", raising another issue.
Are there sUnit unit tests for all the classes in the
system located somewhere? Have changes and
refactorings to the standard system been verified with
unit tests? Or developed test first?

http://www.testdriven.com/modules/mylinks/singlelink.php?lid=39
http://groups.yahoo.com/group/testdrivendevelopment/

>  "Squeak, A Quick Trip to Objectland" is a
>  new edition of a book called "A Quick Trip to
Objectland", which was
>  written in a dialect of Smalltalk other than
Squeak. It makes one
>  suspect that the examples were checked in that
other dialect and taken
>  over to the Squeak book without all getting checked
in Squeak.

I would imagine that a lot of code must of been double
checked since there some Squeak specific stuff in
later chapters. One would think, while they were at
it, they might check the other stuff too? Perhaps,
they didn't write their example code test first or
didn't have any test cases at all?

I also found some other problems with the code in the
previous pages. So what I'm starting to do, as of
today, is to write learning tests with sUnit which
test the example code before I actually run it.
(Earlier I had been doing the examples in a
WorkSpace). This way I get learn Smalltalk, sUnit and
further enhance my Test Driven Development skills at
the same time.

Thanks for sharing what you've learned and the fix,

Anthony

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



More information about the Squeak-dev mailing list