<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-23 21:42 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
2014-07-22 1:29 GMT+02:00 <span dir="ltr"><<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>></span>:<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nicolas Cellier uploaded a new version of Graphics to project The Trunk:<br>
<a href="http://source.squeak.org/trunk/Graphics-nice.296.mcz" target="_blank">http://source.squeak.org/trunk/Graphics-nice.296.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Graphics-nice.296<br>
Author: nice<br>
Time: 22 July 2014, 1:28:48.356 am<br>
UUID: 3f6d869e-9929-4e08-b137-aae22dd3eee6<br>
Ancestors: Graphics-nice.295<br>
<br>
Don't try to accelerate GIF reading by copying the stream in memory.<br>
This should be the purpose of a decent file buffering policy, and if ever that was not the case, then we should fix the file buffering policy rather than trying to patch each and every client site.<br>
<br>
Especially when the patch is testing that the stream is in memory with a class identity to ReadWriteStream!!!<br>
Frankly, how do we know that it's not a RWBinaryOrTextStream ;)<br>
<br>
So why reading an image with a ReadWriteStream?<br>
Oh, sure, this is in ImageReadWriter, so we may need a ReadWriteStream?<br>
No, no, and no!<br>
This thing will either read or write but NEVER read and write.<br>
One simple role, one simple class, no UberPotentSwissKnifeStream with UberComplexStateToManage (readPosition + writePosition + readLimit + writeLimit + readBuffer + writeBuffer + readWriteBufferInteraction).<br>
<br>
What's coming next?<br>
Easy to guess, see what (ImageReadWriter>>on:) does frivously to our stream:<br>
reset??? Hey, ImageReadWriter, why do you take the responsibility to reset the stream? Did you ask the permission? Did you think of possible side effects?<br></blockquote><div><br></div></div><div>the answer is summarized there:<br>
<br>readNativeResourceFrom: byteStream<br> | img aStream |<br> (byteStream isKindOf: FileStream) ifTrue:[<br> "Ugly, but ImageReadWriter will send #reset which is implemented as #reopen and we may not be able to do so."<br>
aStream := RWBinaryOrTextStream with: byteStream contents.<br> ] ifFalse:[<br> aStream := byteStream.<br> ].<br><br></div><div>Ugly says it all.<br></div></div></div></div></blockquote><div><br></div>
</div></div><div>Why not dispatch to byteStream then?</div><div><br></div></div></div></div>
<br></blockquote><div>Because there is a better solution: remove the undue reset from ImageReadWriter>>on:<br>There is no reason why it should reset the stream, that's not its business, and it won't work with some Stream species.<br>
This reset is just a hack necessary when you use a ReadWriteStream for reading...<br>Since people tend to forget it, the reset has been placed at ReadWriteStream consumption site.<br>Maybe a better place for reset would be when creating a ReadWriteStream for reading, but creation message are direction agnostic (do not distinguish reading from writing usage)...<br>
</div><div>But if we create a ReadWriteStream for reading and exclusively for reading - then maybe we'd better just create a ReadStream...<br></div><div>That's all the spirit of my changes.<br><br>ReadWriteStream carries complexity, it has both state for reading and for writing with some unobvious interactions, and requires some hacking like sending #reset and other niceties.<br>
</div><div>But 99% of time we are not going to need this complexity, because in most use cases we will read XOR write, in some cases write THEN read (ReadWriteStream is just there to avoid a copy), but very very rarely interleave read and write.<br>
</div><div>If we just use a ReadStream when we want to read and a WriteStream when we want to write, we better express our intentions, and we simplify code.<br>No use for strange state hacking (reset), not use for ugly class testing (isKindOf:), or its beautified dispatch form...<br>
By the way, how would we name the selector?<br>I have a very speaking proposition: byteStream robustifyForThoseClientExpectingAReadWriteStreamAndHackingStreamStateWithAReset.<br></div><div><br></div><div>Nicolas</div></div>
<br></div></div>