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