I am confused, Camillo. You want to remove them, OK. But what will #writeStreamDo: and so on then get as argument ? Something new ? Or is there already another solution in the image ?
On 25 Jun 2012, at 13:02, Camillo Bruni wrote: > Hi Sven, > > On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote: > >> All in all the switch to FileSystem is very good. File/Directory >> manipulation is much improved. >> >> (But it does create a problem for library/framework writers, like me, that >> want to remain compatible with 1.3 and 1.4) >> >> However, when trying to actually use FileSystem and when looking at the >> current users in the image, I see a problem (coming up) with >> FIleSystemStreams and its subclasses. >> >> They should be binary, but they are silently used as character based, either >> relying on implicit conversions or explicit ones, without proper encoding. >> This is wrong. > > Definitely wrong... > Anyway for now I will completely remove FileSystemReadStreams since they do > not add much value to the system. > Even worse, I think with having yet another stream implementation we > completely confuse the hell out of people! > > see: http://code.google.com/p/pharo/issues/detail?id=6132 > >> Why is there a FileSystemReadStream>>#nextLine ? >> Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone >> of efficient input ? >> Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf …] methods on a >> binary stream ? > > obsolete I would, given that the FileSystemReadStream is going to be removed > >> Because even with these methods that should not be there, the streams opened >> by FileSystem cannot be used for simple parsers or renderers, simply because >> the elementary #next and #nexPut: deal with bytes instead of characters. >> >> Some time ago, I did a quick experiment by adding ZnCharacterReadStream and >> ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I >> include a file out) that solve this problem from my perspective (but they >> don't allow arbitrary #position[:] hacks). >> >> Another question is how buffering works (if present at all), since it seems >> to be hidden in the plugin ? >> >> What do the FileSystem hackers, Cami, Sean, et al, think about this >> situation ? > > :) I vouch for complete removal of said stream implementations and for now > rely on the given FileStream + Co classes. > When time comes ( I hope very soon ), we should adapt a decent streaming > library which cleans up this stupid mess of byte vs char.
