"Andreas Raab" <andreas.raab at gmx.de> wrote:
[snip ]
> 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.
[snip]

Well, I have a bridge to sell you, young man :-)

I agree with the nastiness of the current situation but disagree as to
the desired state. I consider a single class with a tightly defined
primitive interface to be tantamount to early binding when as we all
know, late binding has many advantages.

Ignoring for the moment Russell's point about the file naming issue
(since file names should be a separate class to filestreams etc anyway)
I would suggest that we would benefit from a single FileDirectory class
BUT that said class needs a bridge to the actual machine primitives.

Such a bridge class can be machine/OS/situation specific ie
FileDirectory implements #fileNames by delegating to the currently
selected bridge. A UnixFDBridge would probably open a dir stream, keep
the pointer, use readdir etc and return the array of names. A
RISCOSFDBridge would use quite different means to do the same but
crucially the user code would only see the FileDirectory object.
Another benefit would be that ServerDirectory could be replaced with a
bridge class that handles the ftp stuff but again, without the user
code having to know (Well, probably - maybe there are actually reasons
to have ServerDirectory user accessible. The principle remains though).

The important points are that the user class provides the user protocol
and stores only the abstract state and uses a bridge class to handle al
the details. The bridge class implements messages to support the user
class and stores whatever state it needs to be able to drive the
machine primitives. When snapshotting, the user class can drop the
bridge object(s) since it must be able to recreate them at need.

As another example, consider #directoryContentsFor: - which is a main
interface to the platform prims. It is used to get full info about all
the files in a dir, to get the names of all files and directories, to
get files or directories separately, check for existence and so on.
Building on such a prim is great for porting (barring the complication
of implementing it!) but not very efficient in many cases. Using a
bridge class would allow separate implementations for exists,
filenames, stat-like information and so on when and if appropriate. It
even allows for machine where it is best to (thinking of a complex way
to do it)
find out how many entries exist
allocate an array to suit
iterate, filling the array with names
iterate, fetching stat info
resort by date found in stat info.

Hell, it would allow for a platform to use FFI to access the platform
instead of more explicit primitives. 

Free the primitives from the dungeon! Late binding good, early binding
baaaad!


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Low on thinking gas.