Re: Interpretation of extensions different from Unix/Linux?

["Randy Brukardt" <randy@rrsoftware.com>]

"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). What other criterion could possibly make sense??

>> 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.)

>> 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. (Some OSes don't have directories, so 
Ada.Directories could not usefully do anything in such an environment.) For 
instance, Pattern => "" always matches everything in a directory. It's only 
a problem if you want to go beyond the intended uses for the package. And, 
of course, if some predefined package doesn't do the job for you, then don't 
use it! The predefined stuff cannot do everything for everyone. (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.)

                              Randy.