I think I understand: in a way you go backwards to have better compatibility now. I will have to download a later 2.0 image. Thx.
On 25 Jun 2012, at 14:09, Camillo Bruni wrote: > > 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. >> >> > >
