Re: Interpretation of extensions different from Unix/Linux?

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

On Fri, 4 Sep 2009 21:08:49 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:10he0wbmken48$.1q24z0xzfg8ob.dlg@40tude.net...
>> On Thu, 3 Sep 2009 17:22:44 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net...
>>> ...
>>>> This does not answer my question. Is file manager a typical application?
>>>> How can it be designed in Ada using Ada.Directories? Let us ignore GUI
>>>> issues.
>>>
>>> IMHO, no, it is not a typical application.
>>
>> Criterion?
> 
> Likelyhood of wanting to write it in Ada, of course. (Which ought to be 
> never, as I said below).

90% of any program that provides user interface dealing with files. You
cannot implement file open/save/list without it.

>>> You serve no one by reinventing
>>> the wheel, and file managers are an integral part of every modern OS, and
>>> commonly available on lots of non-modern OSes.
>>
>> So? Calculator program is available on all these OSes. Is it an argument
>> against Ada numeric types having operation "+"?
> 
> False analogy: "+" is useful for lots of things, not just writing a 
> calculator. You are talking about functionality that is *only* useful for 
> writing a file manager or equivalent. (And I'd argue that it isn't even 
> useful for that, but YMMV.)

The analogy is right. The functionality of any file being reachable is
essential to use a file system.

Programs dealing with one or two files  don't need Ada.Directories at all.
Similarly, if there are only two numbers, make them named constants and
forget about addition.

>>> Let the user use what they
>>> are familar with. If you did write one with Ada.Directories (and you 
>>> surely can, you just have to use some OS-specific way of finding roots), it 
>>> would necessarily be a poor imitation of the provided one
>>
>> Ada.Directories *is* a poor imitation of OS-specific file search. Why is 
>> it in the standard? You cannot apply this logic while keeping 
>> Ada.Directories.
> 
> I totally disagree. You can write quite useful programs using 
> Ada.Directories without depending on anything OS-specific beyond whether or 
> not the package is supported at all.

This is just untrue. I already have pointed out that Ada.Directories cannot
be used without OS-specific programming. You cannot get file names without
using string literals which *are* OS-specific. In fact not a single
operation there can be used without OS-specific programming around it,
unless the file name is entered from the keyboard and then used as-is,
which Ada.Text_IO already does. If you put file name into a string literal,
that is OS-specific. To let the user choose files from a list is
OS-specific/impossible. To filter files by names is OS-specific. To compare
files for identity is OS-specific. To compare file names is OS-specific.

> (One obvious 
> example: we couldn't come up with a portable way to define a package that 
> could start other programs. Every compiler has this functionality, but it 
> isn't amenable to describing in Standards terms.)

No problem with that, except the false conception, that such a package
(Ada.Directories is among such) should reflect properties of the underlying
OS. All Ada DB bindings suffer this same illness, which limits their
usefulness but multiplies the count of. This is trivially wrong. You cannot
be OS-specific and portable.

Instead of that, Ada packages should provide an abstraction layer, a model
OS, independent on the target. Note that all modern GUI and other
middleware libraries follow this path. No problem, you can spawn a process
using Glib in an OS-independent way. It would be perfectly possible to
introduce Ada library for spawning processes with three pipes (represented
by Ada streams). I wrote a similar thing for GtkAda based on the Glib
functionality.

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