Re: GUI was Re: why Ada is so unpopular ?

["Randy Brukardt" <randy@rrsoftware.com>]

"amado.alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.12.1074699773.281.comp.lang.ada@ada-france.org...
<<...If GtkAda was going to return a
list of something, shouldn't it ought to be a *Charles* list rather than
something that was specific to GtkAda? ...>>

> Absolutely. This is a fascinating issue. I thought about it when I wrote
here before, but kept
> silent. But now that you've touched it, I'll add a bit. A *lot* of Ada
libraries, including already
> standard ones (e.g. ASIS) and upcoming standard (e.g.
Directory_Operations), deal with a lot
> of data structures, and so they should be using the standard for that
(Ada.Containers, also
> upcoming, AI-302). The result would be clearly a good thing, more cohesion
both in the
> standard and in applications. This is motivation number 1 for
Ada.Containers in my paper
> in Ada-Europe 2004 (about persistent containers, but touching the general
issue in passing).

I can't speak for ASIS, but in the case of Directory_Operations, there is no
place where a container could usefully be used. Containers are mainly useful
in non-critical parts of your application (where time and/or space
requirements aren't critical), and that cannot be said with certainty about
the various standard libraries. Moreover, you certainly don't want searching
operations returning vectors of file names, you would have no idea
whatsoever what the time/space usage of that would be. (Directories with
thousands of files aren't uncommon.) I wrote a package which did that in the
very early days of Ada, and quickly abandoned it because of problems with
large result sets. Of course, if you need a vector of files, just create it,
it's easy enough.

I agree with your basic point (that the libraries of Ada should be
integrated where possible), but the ones that are really bad offenders (like
the Ada.Strings hierarchy) already exist and aren't going to have major
changes in them.

                  Randy.