Re: What about a glob standard method in Ada.Command_Line ?

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

On Thu, 2 Sep 2010 14:25:46 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:198k7jlp1nvhi$.1mq6mu1iorkpi$.dlg@40tude.net...
> ...
>> There are other self-evident requirements. But since it seems that nobody
>> actually uses Ada.Directories, there will be no pressure on the ARG to fix
>> it any soon.
> 
> This is getting silly. I use Ada.Directories heavily in all of my programs; 
> and I used Claw.Directories (on which it is based) for years before that.

That wonders me, because I really see no task, which could be accomplished
with Ada.Directories in a portable way. This is an important point, because
if I would not care about portability I just would use Windows or Linux API
rather than Ada.Directories. I have no idea if GNAT Ada.Directories
actually works under, say, Russian Windows with UCS-2, or for German
Windows with files named in Chinese UTF-16, but I am almost sure that
nobody even tried that.

> Perhaps there is no pressure to change it much because most 
> users don't see any significant problems?

Yes, they see no problems because they don't use it.

> Using a private type for file names would be possible, but it would be way 
> too hard to use;

I don't think so. It could be designed with an appropriate set of
operations like:

   function "/" (Directory : Relative_Path; Name : Wide_Wide_String)
      return Relative_Path;

etc. "a"/"b"/"c" is not much harder than "a/b/c". Anyway hard coded file
names appear only in sample programs. In production code a literal path
were unusable anyway, because it is non-portable. So it should be

   Create (File, My_Documents_Directory / "text" / Text_Content);

which under Windows would yield file path encoded UTF-16:

   "C:\Documents and Settings\Winnie the Pooh\My Documents\text.txt"

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