[Pharo-project] FileSystem question
|working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. "--> 2010-02-14T10:34:31+00:00" cache entry modification. "--> 2010-02-14T10:34:31+00:00" cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. "--> 2010-02-14T10:34:31+00:00" cache modification. "--> 2010-02-14T10:34:31+00:00" cache size I like the way FSFilePluginPrims encapsulate the primitive calls. Stef
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. Lukas On 15 February 2010 18:36, stephane ducasse <stephane.ducasse@free.fr> wrote:
|working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry     cache entry creation.   "--> 2010-02-14T10:34:31+00:00"     cache entry modification. "--> 2010-02-14T10:34:31+00:00"     cache entry size
give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code.
 cache creation.   "--> 2010-02-14T10:34:31+00:00"  cache modification. "--> 2010-02-14T10:34:31+00:00"  cache size
I like the way FSFilePluginPrims encapsulate the primitive calls.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
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
Hi colin You confirmed what I like :) But my question was more about moving entry API to FSReference API. |working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. "--> 2010-02-14T10:34:31+00:00" cache entry modification. "--> 2010-02-14T10:34:31+00:00" cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. "--> 2010-02-14T10:34:31+00:00" cache modification. "--> 2010-02-14T10:34:31+00:00" cache size On Feb 16, 2010, at 8:23 AM, Colin Putney wrote:
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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2010-02-15, at 9:36 AM, stephane ducasse wrote:
|working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. "--> 2010-02-14T10:34:31+00:00" cache entry modification. "--> 2010-02-14T10:34:31+00:00" cache entry size
give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code.
cache creation. "--> 2010-02-14T10:34:31+00:00" cache modification. "--> 2010-02-14T10:34:31+00:00" cache size
Yes, references could provide direct access to the information in the entry. But I made it a separate object for a couple of reasons. The main one is performance. If you need to fetch several pieces of information it's more efficient to make one trip to the disk and keep all the information in one object. I ran into this problem while implementing the directory tree visitor code - it was slow, slow, slow until I implemented FSDirectoryEntry. Colin
participants (4)
-
Colin Putney -
Lukas Renggli -
stephane ducasse -
Stéphane Ducasse