Re: Interpretation of extensions different from Unix/Linux?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 04 Aug 2009 15:04:55 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> 1. It assumes Latin-1 encoding of the file paths
> 
> True, because of the definition of String. What specific OS that Ada.Directories 
> is targeted to has such a limitation?

Maybe MS-DOS?

Latin-1 is a limitation that makes impossible to write OS-independent
programs. BTW, I didn't check it but I suppose that the GNAT implementation
is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
broken twice. Once per design, once by the implementation to fix broken
design.

>> 2. It assumes singe root of the file system
> 
> No, it doesn't. It has no concept of a root.

Is this any better?

>> 3. Even so it provides no way to get the name of the root
> 
> Because it is OS neutral, and there is no independent concept of a root.

An OS-neutral Ada.Directories would provide enumeration of roots. Any
usable Ada.Directories must have the concept of roots nodes.

>> 4. It assumes that directory name can be composed from simple names
>> (Compose is broken for the systems where the syntax of a directory name
>> differs from the name of a plain file.)
> 
> The directory part has to be representable as a single String, but there's no 
> requirement that directory names be the same as a plain file name.

The requirement is implicit because Compose and Containing_Directory do not
distinguish absolute and relative paths, directory and file names.

>> 5. It totally ignores devices, file versions, mount points, URL, URI
> 
> Since they do not exist on all OSes. More evidence of its OS neutrality.

That only makes it unusable. A portable package is not the least
denominator (which is most likely null). It is a mapping to some language
defined concept of a file system. There is no problem to have such a
concept with devices which would work for OS-es that do not have them. The
inverse is wrong.

>> 6. It does not eliminate OS-specific pseudo names, e.g "." and ".."
> 
> Because it is OS neutral.

No, it is because it is not neutral. It fails to abstract proper DAG from a
file system.

>> 7. It does not provide any means to compare and canonize file names in an
>> OS-independent way
> 
> I'm not sure what you mean. A file name is a String; one compares them using 
> String operations. One can use Full_Name to determine if two paths are the same 
> file. Dealing with OS-dependent features, such as case insensitivity, is 
> obviously not part of an OS-neutral pkg.

It is a required part of.

IF file name is a String (which is not!), THEN the operations defined on
String must be semantically meaningful for file names. Standard string
comparison is not meaningful. Hence either the file name is not String or
else "=" is broken.

>> A trivial test is to write a portable program that prints names of all
>> files. With Ada.Directories it is impossible to do.
> 
> It's impossible with any OS-neutral pkg.

This is not true. But if it were true, then I don't understand why
Ada.Directories was introduced.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de