<div dir="ltr"><div>What gives you a view of what would be returned if you sent #back is:<br></div><div>PositionableString (and subclasses): #last</div><div>StandardFileStream (and subclasses): #peekLast</div><div class="gmail_extra">* this last one is matches to #back as defined in MutliByteFileStream.  #last could be used, but since it uses the internal collection instVar, it may give odd results. I don't know - haven't tried it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-cbc</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 6:00 AM, Jakob Reschke <span dir="ltr"><<a href="mailto:jakob.reschke@student.hpi.de" target="_blank">jakob.reschke@student.hpi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I just stumbled upon the behavior of #peekBack. I expected that it<br>
would give me a "preview" of what I would get when I send #back, but<br>
without changing the position of the Stream (like #peek does for<br>
#next). Or in other words, I expected to get the last read (or<br>
written) element.<br>
<br>
As it turned out it answers the next-to-last element instead. There<br>
even is a test case in RWBinaryOrTextStreamTest for this behavior.<br>
<br>
But does it make sense? I have my doubts mainly because of the<br>
inconsistency with the return value of #back.<br>
<br>
There is also #peekLast, which does what I expected, but it is only<br>
defined for File- and WriteStream and the comment says it is intended<br>
to get the last put element, not a last read/extracted/next-ed<br>
element.<br>
<br>
Kind regards,<br>
Jakob<br>
<br>
</blockquote></div><br></div></div>