FileDirectory>>fileExists: (was: Re: [BUG]Unable to load BFAV, various problems )

Russell Penney russell.penney at tincanct.com
Mon Apr 19 00:03:54 UTC 2004


Gentlemen,
   Could one approach to this be to use URI's as Squeak's native file and
directory naming? These could be translated by a primitive to a os native
representation but Squeak users would never see that.
So Andreas's problem below would be resolved because the Directory object
only really holds the URI, thereby being portable. Only when the object
tries to do something would a cached native file format be used.
We come up with a standard set of access points (like the information that
stat and other functions return) and if a particular os doesn't support it,
we have a standard way of returning "not implemented".

I would say it's a lot of work but the benefits would be huge. For example
Monticello respositories would be entered as a URI and one class handles the
distinction between file, http and ftp.

Russell

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Andreas
Raab
Sent: Sunday, 18 April 2004 10:33 AM
To: The general-purpose Squeak developers list
Subject: Re: FileDirectory>>fileExists: (was: Re: [BUG]Unable to load
BFAV,various problems )

> An important thing for us to remember here is that there is no reason
> all platforms have to have identical FilePlugin implementations. The
> codegeneration process is quite able to produce a FilePlugin for *nix
> that is very different to one for win* and the platform specific
> FileStream/FileDirectory classes can use those differing plugins as
> best suited to their needs.
>
> For example, the unix implementation for primLookupEntryIn:index: is
> pretty ugly and it would probably be much nicer for unix to have more
> direct access to opendir, readdir, rewinddir, blenddir etc. DTL has
> already implemented most of this in DirectoryPlugin and it could be
> added to FilePlugin for unix.

Generally, I'm against this - it makes it a *lot* harder to write good
cross-platform code if you have to deal with the fact that the different
platforms have very different tradeoffs and implementations. If it weren't
for historical reasons, I'd rather get rid of "one class per platform"
approach and have a set of clearly cut primitives which include the
appropriate abstractions. To give an example, in the past I had been bitten
by using "proper objects" instead of "directory names" - try to ship an app
from one platform to another which remembers the relative directory
"foo/bar" in the form of a [XYZ]Directory. It horribly breaks. I'd rather
opt for a single solution into which the platforms MUST map their
directories appropriately with a clear-cut set of primitives.

Cheers,
  - Andreas







More information about the Squeak-dev mailing list