CVS difference for ais/ai-00248.txt

--- ais/ai-00248.txt	2001/06/02 04:13:15	1.4
+++ ais/ai-00248.txt	2001/10/02 01:27:51	1.5
@@ -1,4 +1,4 @@
-!standard A.15 (00)                                00-11-28  AI95-00248/01
+!standard A.15 (00)                                01-09-25  AI95-00248/02
 !class amendment 00-11-28
 !status work item 00-11-28
 !status received 00-11-28
@@ -38,7 +38,7 @@
 with Ada.IO_Exceptions;
 package Ada.Directories is
 
-    function Get_Current_Directory return String;
+    function Current_Directory return String;
     procedure Set_Current_Directory (Directory : in String);
 
     procedure Create_Directory (New_Directory : in String;
@@ -88,7 +88,7 @@
 directory name strings is implementation-defined. A @i<directory entry> is a
 single item in a directory, identifying a single external file or directory.
 
-function Get_Current_Directory return String;
+function Current_Directory return String;
     Returns the directory name string for the current default directory. The
     name returned shall be suitable for a future call to Set_Current_Directory.
     The exception Use_Error is propagated if the external environment does not
@@ -253,7 +253,7 @@
 The names of the routines are based on those used in POSIX and GNAT. Claw
 uses shorter names based on the idea that the parameter and/or prefix will
 make it clear what type of object is being created. For example,
-Create_Directory is Create, and Get_Current_Directory is Get_Current. This
+Create_Directory is Create, and Current_Directory is Current. This
 seems too radical.
 
 GNAT and Claw provide an "open" (non-iterator) version of the directory
@@ -274,6 +274,14 @@
 wildcard characters. This is difficult to convey in implementation advice;
 it probably would appear only in the AARM.
 
+The package is defined as a child of Ada. This is necessary as the package
+is designed to work with all kinds of files, so it would be inappropriate for
+it to be a child of any specific IO package, and making it a child of
+IO_Exceptions also seems inappropriate. Moreover, we could cause conflicts by
+defining grandchildren of Ada, but not for children of Ada (since it is illegal
+to compile children of Ada, and implementors should not define their own,
+while there are no such restrictions for grandchildren of Ada).
+
 !ACATS Test
 
 !appendix
@@ -1954,5 +1962,83 @@
 as part of working on the "file/directory services" amendment AI.
 
 Reference: http://pro.wanadoo.fr/adalog/compo2.htm
+
+****************************************************************
+
+From the minutes of the Leuven meeting (May 18-20, 2001):
+
+It was noted that the package seems to be too high in the hierarchy of
+predefined packages. Randy notes that this package works with all sorts of
+files, so it would be inappropriate for it to be a child of any specific IO
+package, and making it a child of IO_Exceptions also seems inappropriate. If
+Ada 95 had defined a package IO that was the parent of all of the IO packages,
+then this package could go there, but of course Ada 95 does no such thing.
+Moreover, we could cause conflicts by defining grandchildren of Ada, but not
+for children of Ada (since it is illegal to compile children of Ada, and
+implementors should not define their own, while there are no such restrictions
+for grandchildren of Ada).
+
+Change the name of Get_Current_Directory to Current_Directory.
+
+Steve M. suggests that Remove_Directory ought to say that non-empty directories
+are not deleted. After some discussion, it is suggested to add Create_Tree
+(which makes all directories needed in the name) and Remove_Tree (delete
+everything in the named tree, including directories) to the package. Steve's
+suggestion is adopted.
+
+It is also suggested to add Delete (by name [string]) to the package. Rename
+(Old_Name, New_Name) should also be added. This should be described as changing
+the name of the file from Old_Name to New_Name. There should be an
+implementation requirement for this to work at the same level in the same
+directory (others may raise Use_Error).
+
+The Name routine for a directory entry should be split into a Simple_Name and
+Full_Name routine.
+
+Pascal suggests that there should be some way to get the parent directory.
+
+First Erhard, and then Steve M. express confusion about how the directory
+searching iterator works. Randy notes that if Ada experts can't figure out the
+POSIX iterator mechanism, what chance do users have? It is suggested to add a
+limited (type) handle searching mechanism, rather than the current iterator
+scheme. The suggestion is made that the directory searching stuff be put into a
+separate child unit to avoid clutter.
+
+Pascal comments that he doesn't like all these operations taking file names,
+and that he would prefer a full-fledged Directory_Entry abstraction, much like
+Text_IO has a File_Type abstraction. There would be an operation to resolve a
+name to obtain a Directory_Entry, and various operations on Directory_Entries.
+The group appears unconvinced.
+
+A request for file name composition/decomposition functions was made by Tucker.
+Randy notes that these are very tough to do right. The group would like to see
+these.
+
+Steve M. would like to see a way to create links. Others note that the links on
+Windows or Mac aren't the same as the links on Unix, so a common definition
+would be hard.
+
+On Sunday, Randy brings up a recent conformity assessment problem, which is
+somewhat related to this AI. A.8.2(22) says "If an external environment allows
+alternative specifications of the name (for example, abbreviations), the string
+returned by the function should correspond to a full specification of the
+name." The ACATS has always tested this as if it were a requirement. However,
+some implementations have not been following this requirement (and this fact
+was overlooked by the testers). Should this "should" be a "shall" (a
+requirement) or shall it remain a "should" (an Implementation Advice)?
+
+There is definitely a serious overhead (it is necessary to call getcwd() on
+every Open and Create), and there are implementations which have strayed. The
+best solution is to give users an appropriate directories package, and
+eliminate this requirement altogether.
+
+Randy says that the immediate problem is three ACATS tests (from ACVC 1.11)
+which require this behavior. With the above solution, the best course of action
+is to withdraw these tests (they have no other value). The general agreement is
+that a good directories package makes this requirement unnecessary. We should
+plan to remove this requirement when a directories package is standardized. No
+one supported making this a "shall". Randy will integrate this (and associated
+operations, such as a Simple_Name => Full_Name routine) into the directories
+package.
 
 ****************************************************************