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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,15267b2c375b45c2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-22 12:06:38 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!proxad.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: sk Newsgroups: comp.lang.ada Subject: Re: Ada Component Registry proposal Date: Wed, 22 Oct 2003 14:13:16 -0500 Organization: Cuivre, Argent, Or Message-ID: References: <3F92BEAA.9030004@comcast.net> <3F96B96E.3000707@comcast.net> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1066849462 6408 80.67.180.195 (22 Oct 2003 19:04:22 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 22 Oct 2003 19:04:22 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020828 X-Accept-Language: en-us, en X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:1455 Date: 2003-10-22T14:13:16-05:00 "Robert I. Eachus" : > Right now the XML ... > ... ... > under Ada 83. And ... Firstly, I am not too sure about how realistic the scenario of having both Ada83 and Ada95 libraries co-residing in the same development environment is. It was just an example of things that need to be thought of. My very limited exposure to cross-compiling on Linux suggests that 2 completely separate libraries are maintained even if the vast majority of the code is the same. What do I think ? I don't think I understand all the implications of what you are saying since I don't understand XML or have GNADE installed :-) However, since I am foaming at the brain for something, here are my thoughts from march this year NOTE: I am not a big fan of expanding the "Ada.*" or "Interfaces.*" hierarchies. The "Ada.Strings.*" packages seem "alien" to me as part of the ARM hierarchy and really should be (*my* opinion) in the conceptual new package hierarchy. Limit the ARM hierarchy as I quote Larry Killigan suggesting in one of the following messages. -- 2003-05-03 Re: Ada2005 clear scressn etc. ---------------------- > Hi, > > : > > As a external library. I don't see the need for it. I mean next > > will be that we should have some sort of GUI standard in the > > Ada standard. > > In case anybody is starting a voting process on this, I am in the > group of hoping that specific platform needs > are NOT incorporated into any new language standards. > > Let the market decide on useful *external* libraries, but do not > burden the language itself with items possibly subject to fashion > or politics. > > Eg, Sockets : Windows has an API for sockets, the rest of the world > has another. I would not like for Ada, a few years from now, tied > to the obsolete socket API when the politics gets sorted out and > one API is accepted by all. Also especially since the abstract concept > of "sockets" might have changed altogther and be called "connection" or > "channel" or something. -- 2003-06-03 Re: Ada2005 clear scressn etc. ---------------------- > Hi, > > Stephen.A.Leake@nasa.gov : > > ... ANSI standard ... > > I was more panicing over the thought that the language > be bound to some possibly transient fashion and hadn't > stopped to consider some never dying, ubiquitous things > like the ANSI terminal standard. > > However, I tend towards the comment > > > Because the Ada standard should be for things that require > > support from the compiler vendor. > > and subsequent comments on the response cycle for a set of > libraries. > > With that thought, how about an official but very flexible > and distinctly separate package hierarchy ? > > (.. and I am sure it has been discussed before or there are > comments as part of the Ada200y process, sorry for lack of > opportunity to fully investigate. Also please note that I > am not familiar with any of the ongoing Ada library projects > or the "C++" standard library so, again, sorry if this is > a rehash of other discussions or duplication of ideas so > RTFM me, with URL, if appropriate). > > Standard > Ada.xxx > Interfaces.xxx > System.xxx > > Libraries.xxx > > "Libraries" just a graft point, nothing significant about > the name. "Libraries" would, by agreement, have some invarient > subtrees. Perhaps two levels of abstract/conceptual packages > before specific solutions are grafted into the tree ? > > Libraries.Vendor (invarient, children as needed) > .Gnat. > .Os_Lib; > ... > .RRSoftware > .Claw > ... > > Libraries.Host (invariant, children as needed) > .Linux > .Windows > .Win32Ada > > Libraries.Host_Interfaces. > .Console. > .ANSI_Terminal > > .VT100_Terminal > ... > .Graphical > .Win32Ada renames Libraries.Host.Windows.Win32Ada > .GtkAda > ... > .File_System > ... > .Network > .Transport > .Sockets > ... > .Protocols > .Smtp > .Http > ... > .etc > > Libraries.Objects_And_Methods > .Containers > . > > .Strings > for "Libraries.Objects_And_Methods"> > > Libraries.Standardized_Interfaces > .Posix > .RFCs > > etc > > There are a lot of crossovers, but Ada has the "renames" > mechanism which could associate "Libraries.Vendor.Gnat.Directory_Operations" > for example, > with "Libraries.Host_Interfaces.File_System.Directories" > > This needs a lot more thought and work (rearrangment, better > nameing, interdependencies, circularity, management burden etc), > however, it could provide a more cohesive framework into which > APIs would fit without burdening the core language or its "Ada.*" > package hierarchy. ----------------------------------------------------------------------- -- ------------------------------------------------- -- Merge vertically for real address -- -- s n p @ t . o -- k i e k c c m -------------------------------------------------