Re: Ada Component Registry proposal

[sk <noname@myob.com>]

"Robert I. Eachus" <rieachus@comcast.net>:

 > Right now the XML ...
 > ... <snip> ...
 > 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,
 >
 > <randhol+news@pvv.org> :
 > > 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
 > <randhol+news@pvv.org> 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 <Kilgallen@SpamCop.net> 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
 >             <Perhaps the M.Feldman terminal package >
 >         .VT100_Terminal
 >         ...
 >     .Graphical
 >         .Win32Ada renames Libraries.Host.Windows.Win32Ada
 >         .GtkAda
 >         ...
 >     .File_System
 >         ...
 >     .Network
 >         .Transport
 >             .Sockets
 >             ...
 >         .Protocols
 >             .Smtp
 >             .Http
 >             ...
 >     .etc
 >
 > Libraries.Objects_And_Methods
 >      .Containers
 >          . <The current Container library project perhaps>
 >
 >      .Strings
 >          <Just "Ada.Strings.*" as an example of the purpose
 >           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
-------------------------------------------------