[Pharo-project] FIleSystemStreams

Sven Van Caekenberghe sven at beta9.be
Mon Jun 25 08:21:29 EDT 2012


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.
>> 
>> 
> 
> 





More information about the Pharo-dev mailing list