Re: OO Style with Ada Containers

[Matthew Heaney <mheaney@on2.com>]

On Nov 19, 8:44 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 19 Lis, 03:53, Matthew Heaney <matthewjhea...@earthlink.net> wrote:
>
> Can you convince me that Ada.Containers is closer to STL than to Java
> containers (for example)?

But the burden of proof is on you, to prove that the container library
is *not* closer to the C++ than it is to the Java containers!  (And
since I know C++ but not Java, such a proof would indeed be
interesting!)


> If not, then why it is repeated so often
> that Ada.Containers were influenced by STL?

You can read my original library proposal here:

http://home.earthlink.net/~matthewjheaney/charles/ai302.txt

As I stated then:

"This library API is modeled on the STL.  It has the same containers
as
the STL does, using the same container names and semantics.  If you
know
the STL already then you will instantly understand how this library
works.  It does not have any of the STL algorithms, but that's only
because I wanted to keep the API small (and not because it's not
possible to support STL-style algorithms -- it is).  The API described
here has exactly the minimum set of containers I believe all Ada
developers need, in exactly the form they need it."


> Do you by any chance find
> something in C++ that is worth imitating? :-)

Yes, of course: the STL.


> I don't claim that the designers of Ada.Containers didn't have STL in
> mind when taking some decisions, but the essence [*] of STL just
> didn't get there.

Well, the library is modeled on the STL.  There are necessarily
differences, because the languages are different, and my design
philosophy was (and is) to use Ada idioms where appropriate.


> >  Ada has other mechanisms, such as nested procedures and
> > downward closures, and the container library was designed to use the Ada
> > mechanisms.
>
> How can I use these mechanisms to make iterator adaptors?

A generic algorithm in Ada would look something like:

generic
   type Cursor is private;
   with function Next (C : Cursor) return Cursor is <>;
   with function Has_Element (C : Cursor) return Boolean is <>;
   ...
procedure Generic_Algorithm (C : Cursor);

You can instantiate this on the container types directly, e.g.

package Integer_Vectors is new Vectors (Integer);
use Integer_Vectors;

procedure Algorithm is new Generic_Algorithm (Cursor);

This instantiation will deliver every integer element in the vector.
An iterator adapter just means replacing the cursor operations for the
container with something else, e.g.

function Return_Odd_Only (C : Cursor) return Cursor is
  CC : Cursor := C;

begin
  while Has_Element (CC)
    and then Element (CC) rem 2 = 0
  loop
     Next (CC);
  end loop;
  return CC;
end Return_Odd_Only;

procedure Algorithm is
  new Generic_Algorithm
  (Cursor,
   Next => Return_Odd_Only,
   others => <>);  -- verify syntax

procedure Op (V : Vector) is
begin
   Algorithm (V.First);
end;


> Consider a
> filtering iterator that automatically skips unwanted (for the given
> predicate) elements.

See above for an example.


> Consider a virtual iterator that does not have
> *any* container behind, but can serve as a sequence generator. And so
> on.

But the generic algorithms depend only on a cursor as a generic formal
-- the algorithms aren't tied to containers directly (which was
Stepanov's great insight).  For example, let's use the algorithm above
with an array:

type Integer_Array is (Positive range <>) of Integer;
-- the "container" type

procedure Op (A : Integer_Array) is
   function Has_Element (J : Integer) return Boolean is
   begin
      return J <= A'Last;
   end;

   procedure Algorithm is
     new Generic_Algorithm
     (Cursor => Integer,
      Next   => Integer'Succ);

begin
   Algorithm (A'First);
end;