The naming conventions seem to be a bit inconsistent: for example, why not

...

aStream := 'aGivenFileName' asFile reader.

readStream

...

'aGivenFileName' asFile reader: [ :str | aChar := str next ].

and withReadStreamDo:?

Historically Rio was designed to use the message eating Null as part of its way of thinking. So typically #reader was equivalent to #readStreamOrNull. The "Null thought police" "encouraged" me to give up that idea.

Also Rio used to have adaptors, for handling different types of files, and would ask the adaptor for a file specific #reader, the adaptor would implement #readStream if appropriate, but there was/is no expectation that the reader would have to be a stream. Some filetypes were expected to have higher level readers.

The adaptor/reference pair evolved. Having moved a lot of the functionality into the file system executor, it turned out that the reference class hierarchy didnt have any code in it, so the adaptor/reference hierarchies merged. So therefore subclasses of File/Directory may be directly specialised. Having done this they could define their own interface onto their file type, so now #reader doesnt have to be generic anymore and could be changed/mirrored by readStream.

To be honest I dont really like withReadStreamDo:, I wrote the original Rio API before coding things, and designed what I wanted to see.

I switched from File/Directory to just File in GNU Smalltalk 3.1.

In Rio the majority of the code is in File, Directory inherits and adds methods for moving files between Directories, such as #addTree:. I like having files represented by 'a File' and directories represented by 'a Directory', having gone to the effort of separating them a little, though in truth Directory would be the equivalent of your File, since it implements everything.

Keith

Casimiro de Almeida Barreto wrote:

Keith Hodges escreveu:

...

Hello Casmiro,

great to see you using Rio. The latest version has moved away from using "Rio" in the code and is now (for better or worse) using classes called File/Directory.

Rio doesnt use exceptions very much at all for various reasons. It is relatively easy to test for existence, and there are other utilities provided.

In your case where you want a basic stream,

"returns nil if the file does not exist" aStream := 'aGivenFileName' asFile reader.

"returns nil if the file does not exist" data = 'aGivenFileName' asFile contents.

"The reading block is ignored if the file does not exist" 'aGivenFileName' asFile reader: [ :str | aChar := str next ].

"an explicit checks for existence are available via" 'aGivenFileName' asFile ifFileDo: [ :f | f contents ]. 'aGivenFileName' asFile ifExistsDo: [ :f | f contents ]. 'aGivenFileName' asFile ifAbsentDo: [ :f | f touch ].

The latest Rio is available from Universes, be prepared to replace senders of asRio with asFile/asDirectory

thanks for the feedback, knowing the above wold you rather have exceptions still?

best regards

Keith

Hello Keith,

Working in a Fedora rel 10 intel box I've had the following problem:

aStream := self myFileName asFile reader. ... [ aStream atEof ] whileFalse: [ aLine := aStream nextLine. ... ]

If the file is a text file created in Linux, then it will read only one line. If the file is a CrLf text file (Microsoft) it will read the total number of lines plus 1. Besides, many of the reads will be twisted (with the Cr char as part of the string).

When I do:

aStream := CrLfFileStream fileNamed: self myFileName.

Things work properly with:

aLine := aStream nextLine.

if I have a dos text file (crlf)

Obviously: aLine := nextString also fails.

How to fix the behaviour of nextLine for common Linux text files ???

Best regards,

Casimiro

Thanks for the feedback, I fixed this in latest.

CrLfStream has been replaced by MultiByteFileStream and this can be set to read in various modes, it is also supposed to detect the line ending convention. Unfortunately this was disabled by default. Rio was explicitly telling binary streams that they were binary streams, but was omitting to tell ascii streams to enable lineEndingdetection.

thanks for the feedback.

Keith