stephane ducasse <stephane.ducasse@free.fr> wrote:
I like the way FSFilePluginPrims encapsulate the primitive calls.
Lukas Renggli replied:
I think this is a separate object because some filesystems might not provide this information or might provide a different set of information.
An external filesystem (FTP, HTTP) might not know the size, creation or modification timestamp. Zip archives might provide different information. I guess that's the reason why this is a separate object.
Sort of. That's the rationale for handles. FSDiskHandle isolates the stream from the primitives, so it's possible to have the primitives in the handle and still have the stream work with different types of filesystems. I moved the primitives to a separate object for a several reasons: One was to make them private. The stream should not be able to call primitives directly, and putting them in a separate object that the stream doesn't have access to makes that clear. (It's not full capability security because the stream can violate encapsulation via #instVarAt: or other trickery, but the need to do that is a sign that you shouldn't). Second, the primitives provided by FilePlugin aren't ideal, and eventually I want to have some primitives designed specifically for Filesystem. It wouldn't be a drop-in replacement for FilePlugin, but if the FilePlugin primitives are all in one place, it should be fairly simple to port to another primitive object with a slightly different protocol. Finally, I like the way it looks: Primitives close: id is nicer than self primClose: id. at least to my eye. :-) Colin