Re: encapsulating directory operations

On 21.05.2025 11:45, Paul Edwards wrote:

"Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message
news:100je5c$2l1b2$1@dont-email.me...
 

certainly useful to be supported as library functions. And I'd
write and provide directory abstractions also as add-on library
functions (as opposed to part of a language; but my opinion on
that is not strong). Historically other languages even missed to
>
To sum up; on the way from the OS entity to the user interface
there's various abstraction levels. Depending on the service I'd
like to provide I'd probably choose different abstraction layers.
I _don't_ think that a directory abstraction should be *inherent*
part of the C language, but if necessary provided as a _library_.

 
Sorry if I didn't specify that clearly.
 
Of course I expect the directory handling to be in a library.
 
Just as fopen() is in the library section of the C90 standard.
 
The question is whether at least "half baked" directories
should/could have been added the C90.

The problem I see is that there are so many different types of
directories depending on the OS; plain files (no directories),
hierarchical with features like versions (VMS), a fixed set of
individual hierarchies (DOS/Win), versions with one directory
tree but with various attributes (e.g. access flags, ACLs), etc.

It's thus a question of what abstraction you can and want provide.
And that appears to be simpler with files than with directories.
Simula, for example, has modeled files in a hierarchy of file
types (infile, outfile, printfile, etc. as classes collected in
an own class and usable like a module) and it would probably have
been easy (i.e. now, not in 1967) to also model various types of
directories and their properties as well in such an OO environment.

"C" is simple (from its basic concepts), and of course you could
collect some directory functions, or maybe support even different
types of directories in a flat library with lot of special cases
programmed to support if not all at least a couple directory types.

The question of what constitutes a "C" language w.r.t. the various
standards released over time has elsethread already been answered,
and I don't want to (and don't have to) add anything to that.

Because of the various aspects mentioned I wouldn't add that to
C90 (but I also don't care much). From a programmers' perspective
I'd not be delighted to have some library function be only defined
for one "incompatible" version. I'd keep it in a separate library
(as already said). Is there a reason that it would be standardized
as part of the "C" language? I think, only if there's a sufficient
coherence across various directory models (which I don't see).

I had in most cases programmed on operating systems of one family;
I never needed a "C" language library abstraction level of access
to directories, I always used the OS specific libraries for that.
My needs were and are covered by POSIX here.

I see that a set of dedicated directory function [_restricted_ to
a specific directory model] could be useful, but I don't see the
necessity to add that to an old "C" language standard branch.

(I'm not sure whether we spoke about the same or different things,
or on cross-purpose, so I'll leave the discussion for the moment.)

Janis

 
It would have violated the "existing practice" spirit (which
doesn't bother me - note - I failed to explicitly state this),
but it wouldn't have violated the "portable" spirit.
 
So long as you are careful and keep it "half-baked", you
can have a portable file system in the spirit of C90
portability.
 
There were reasons this couldn't be done in 1990 (actually,
it is C89 that matters here, so 1989 - and in fact, it was a
static draft even earlier than that). But I wish to do it now,
belatedly.
 
BFN. Paul.