When I read that first line of your post, my impression/expectation was the
same as yours.
Intuitively #back and #peekBack should return the same value.
But my comments are face-value only, without a deep familiarity of
streams.  Maybe someone else can provide historical & future context.

Presuming it was broadly accepted this "should" be the behaviour of
#peekBack, the problem with changing its behaviour is the effect on
existing users, and also cross-dialect compatability. "Ideally" Squeak/Cuis
would be ammendable to such a change, and then one approach could be a
little dance using an interim #peekBackFromCursor so the existing #peekBack
can be deprecated for one version (to avoid silent corruption of
application logic) then restoring #peekBack with the new behaviour.    A
slow process, but such small changes accumulate over time to improve things.

Alternatively, we just leave #peekBack as-is and permanently introduce
#peekBackFromCursor or similar.
Maybe such changes would be superseded by XStreams anyway (not really a
reason stop improving current system anyway.)

cheers -ben


On Wed, Jun 21, 2017 at 9:00 PM, Jakob Reschke <jakob.reschke at student.hpi.de
> wrote:

> Hi all,
>
> I just stumbled upon the behavior of #peekBack. I expected that it
> would give me a "preview" of what I would get when I send #back, but
> without changing the position of the Stream (like #peek does for
> #next). Or in other words, I expected to get the last read (or
> written) element.
>
> As it turned out it answers the next-to-last element instead. There
> even is a test case in RWBinaryOrTextStreamTest for this behavior.
>
> But does it make sense? I have my doubts mainly because of the
> inconsistency with the return value of #back.
>
> There is also #peekLast, which does what I expected, but it is only
> defined for File- and WriteStream and the comment says it is intended
> to get the last put element, not a last read/extracted/next-ed
> element.
>
> Kind regards,
> Jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170622/0221ac9d/attachment.html>