On Fri, Jun 30, 2017 at 5:56 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

"peekBack deceived"
>

Strangely, I can't shake the idea this is a good name for a SciFi Thriller
movie.
cheers -ben



> http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-
> July/179285.html
>
> we can't reasonnably drag too many of these inconsistencies...
>
>
> 2017-06-22 5:48 GMT+02:00 Ben Coman <btc at openinworld.com>:
>
>> 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/20170630/33a5ffb7/attachment.html>