On 2012-06-25, at 13:56, Sven Van Caekenberghe wrote: > I am confused, Camillo. > You want to remove them, OK. > But what will #writeStreamDo: and so on then get as argument ?
currently (2.0.158) that returns a MultiByteFileStream > Something new ? > Or is there already another solution in the image ? basically I wanted to make sure we return the same FileDirectory / FileStream does the only problem so far is that the memory filestream still uses the FS streams, which I changed in http://code.google.com/p/pharo/issues/detail?id=6132 That will simply return a WriteStream on the internal ByteArray for now. > 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. > >
