From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f6f11ace4643916c X-Google-Attributes: gid103376,public Path: controlnews3.google.com!news1.google.com!news.glorb.com!wn51feed!worldnet.att.net!attbi_s02.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: Ada 2005 presentation at Ada-Belgium event now on-line References: X-Newsreader: Tom's custom newsreader Message-ID: NNTP-Posting-Host: 24.6.132.82 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s02 1083708656 24.6.132.82 (Tue, 04 May 2004 22:10:56 GMT) NNTP-Posting-Date: Tue, 04 May 2004 22:10:56 GMT Organization: Comcast Online Date: Tue, 04 May 2004 22:10:56 GMT Xref: controlnews3.google.com comp.lang.ada:260 Date: 2004-05-04T22:10:56+00:00 List-Id: The "tree structured directories" addressed by Ada.Directories are on their way out. Under Windows, for instance, there's a separate directory called the Registry (which I understand will disappear in the next major release) and there is a (rarely used) additional directory level called file resource forks. It doesn't appear that Ada.Directories applies to either of those. It's also become rather obvious that objects need to be "filed" in multiple ways; a single tree is inadequate. The next version of Windows is supposed to address this issue (searching? relational database?). Ada.Directories will nicely standardize the multiple incompatible directory operations packages of today, but that part of Ada05 will become obsolete not long after introduction. IMHO