[Pharo-dev] In-memory FileSystem write streams not being polymorphic
camillobruni at gmail.com
Mon Nov 11 08:44:31 EST 2013
On 2013-11-11, at 14:19, Nicolás Papagna Maldonado <nicolas.papagna at gmail.com> wrote:
> Hi all!
> I've been working in a fix of PharoFilesOpener and decided to test the current behavior first before changing it, so I extracted the dependency to FileSystem and tried to use an instance created through FileSystem memory for testing.
> The code gets the write stream for a file and then sends the #isReadOnly message to do some stuff.
> The thing is that the streams returned form the in-memory file system are instances of WriteStream (see MemoryHandle >> writeStream) instead of StandardFileStream (see FileHandle >> writeStream) and so they don't respond the #isReadOnly message.
> Is this the expected way the in-memory file system should work? Shouldn't it return polymorphic file streams?
You are absolutely right, it definitely should, but this requires a bit of work (see below)
> If this is a bug, what change would you recommend to do?
> I was thinking about returning StandardFileStreams instances from MemoryHandle >> writeStream.
The memory filesystem works by definition in the image, whereas the StandardFileStream is bound
to external file operations through the primitives (see for instance #basicNext).
I think you have two choices here:
1. rewrite your code that it does not rely on the #isReadOnly but rather check up front
if you can read the file
2. implement your own proper FileStream that works on the internal ByteArray of the
memory FileSystem (maybe there is already a decent solution somewhere in the Zinc code)
or of course, you start looking at porting XStreams to pharo ;), which on the long run will
solve many more problems. The current situation is not that satisfactory :/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 447 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Pharo-dev