Re: Ada.Directories problems, a summary

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

On Mon, 5 Jan 2009 19:23:27 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:d6mq43hiz19n$.1x02dgs0h5862$.dlg@40tude.net...
>> On Fri, 2 Jan 2009 16:57:07 -0600, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote
>>>
>>>> After experimenting with Ada.Directories I collected the issues I think
>>>> must be addressed to make Ada.Directories more usable:
>>>
>>> You should send your suggestions to Ada-Comment as a comment on AI05-0049
>>> (which is about various additions to Ada.Directories). I'm supposed to
>>> working on that in the next month or so, and I wouldn't mind a discussion 
>>> on
>>> it. But not here...it should be done in the context of the AI so it can 
>>> be
>>> recorded there.
>>
>> I don't have a concrete proposal, it was merely complains than something
>> constructive. So I wished to hear what other people think about it. At
>> least to grope after the range of changes felt necessary/desired. For
>> example, I would like to have different string types for simple name,
>> directory name, full (absolute) name. There are other general design
>> issues. Like a clean separation of physical and path/name-only file
>> operations. Desired? Possible? (in the context of case-insensitive issue
>> under Windows)
> 
> They're already completely separated (the AARM makes this clearer), so I'm 
> not quite sure what you mean. The operations on strings are completely 
> logical, never physical; they make no use of the machine state (other than 
> the name of the current directory). If the wording doesn't make that clear, 
> that's probably my fault, but it surely is the intent.

I see. Never read RM, do AARM! (:-))

(The problem with Containing_Directory is when there is no containing
directory in the path (relative name) AARM instructs to return ".". This is
non-portable.)

But what about different types? It is really not an Ada style to mix
everything into one type. With different types the controversies absolute
vs. relative, partial vs. full names could be easier to solve. Ugly Compose
could become a set of "&" functions, etc.

Open, Create etc operations in other packets would have overloaded
counterparts with absolute and relative file names, but this is not a big
deal. And one should do this anyway, because the name encoding issue must
be solved.

> (I would have preferred that those operations were in a totally separate 
> package from Ada.Directories, but I lost that argument.)

Yes, Ada.Directories is a too large.

>> Thank you for the AI number.
>>
>> BTW, can Ada-Comment become a news group rather than a mailing list?
> 
> Why would we want to go from one stone-age technology to another?

Bronze-age was the best time. (:-))

News group is IMO superior to the modish "iron-age" wiki. It is
irreversible, supports treaded views and reasonable search.

> Besides, 
> the point of Ada-Comment is to be all-inclusive -- everybody has access to 
> e-mail. Access to newsfeeds has been getting harder to come by, and lots of 
> people don't have good access (my ISP doesn't offer any, for instance). I 
> could see going to some web-based format (perhaps a blog), but that would 
> imply a need for more filtering than now, not less (link spammers are a 
> major problem for blogs). Not sure what we'd gain other than prettier text.

A news server with a web interface under http://www.adaic.org/?

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