new Smalltalk programmer's thoughts

Chris Muller chris at funkyobjects.org
Tue May 2 16:53:04 UTC 2006


Stream positioning is *between* elements, array-indexing is *at* a particular element.
 
 I see them as two different kinds of access, both 1-based..
 
 

----- Original Message ----
From: Wolfgang Helbig <helbig at Lehre.BA-Stuttgart.DE>
To: squeak-dev at lists.squeakfoundation.org
Sent: Monday, May 1, 2006 3:45:17 PM
Subject: Re: new Smalltalk programmer's thoughts

Hi Yoshiki,
as you and others pointed out:
>  Also, in Smalltalk, Streams are 0-based as nicolas and others
>mentioned.
>  The AltoFileStream should've follow this convension, instead of
>allowing [1..size] indices.

I agree! It not only *should* follow this convention, but it *must* follow it.

After all, I programmed AltoFileStream to be used by the Hobbes Emulator, which
expects a FileStream to read the snapshot. So I subclassed FileStream and tried
to implement its protocol. Later I found out, that ReadStream suffices for this
purpose. Anyway, I had to implement the semantics of #postion and #position: as
expected by the Hobbes Emulator. Since I didn't find a specification of that
protocol, I naively assumed that position is supposed to be in [1..size]. After
all, this is the natural range of indexes in Smalltalk, isn't it?

But I was utterly wrong, which I found out when I tried to make Hobbes read the
snapshot from an AltoDisk.

The position is supposed to be in range [0..size]. Which looks very unnatural to
me. With this range, position looses the nice property of being a valid index.
So you have to make sure you never access the byte indexed by the current
position. Instead you always use current position + 1. Unix files are more
elegant in this respect. Their position is in the range [0..size), which happens
to be the range of valid "Unix indexes". And I feel much more comfortable with
[0..size) than with [0..size] or [1..size].

Thanks to everyone on this list for their answers! I've learned a lot!

Greetings
Wolfgang, a humble programmer
--
Weniger, aber besser.









More information about the Squeak-dev mailing list