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
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> stephane ducasse <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> |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