PositionableStream >> peekBack

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PositionableStream >> peekBack

Jakob Reschke
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PositionableStream >> peekBack

Ben Coman
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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PositionableStream >> peekBack

Nicolas Cellier
we can't reasonnably drag too many of these inconsistencies...

2017-06-22 5:48 GMT+02:00 Ben Coman <[hidden email]>:
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 <[hidden email]> 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








cbc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PositionableStream >> peekBack

cbc
In reply to this post by Jakob Reschke
What gives you a view of what would be returned if you sent #back is:
PositionableString (and subclasses): #last
StandardFileStream (and subclasses): #peekLast
* 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.

-cbc


On Wed, Jun 21, 2017 at 6:00 AM, Jakob Reschke <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PositionableStream >> peekBack

Ben Coman
In reply to this post by Nicolas Cellier


On Fri, Jun 30, 2017 at 5:56 AM, Nicolas Cellier <[hidden email]> wrote:

"peekBack deceived"

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

 
we can't reasonnably drag too many of these inconsistencies...


2017-06-22 5:48 GMT+02:00 Ben Coman <[hidden email]>:
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 <[hidden email]> 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












Loading...