Re: Two approaches of iterators for the key-value pairs

[Simon Wright <simon@pushface.org>]

Simon Wright <simon@pushface.org> writes:

> Brad Moore <bmoore.ada@gmail.com> writes:
>
>> My sense is that if you dont need a container as part of the
>> abstraction, then perhaps it's better to just provide an Iterator
>> type. All the existing containers already were containers, so for
>> those it made sense to make them Iterable containers.  Ada.Directories
>> and Ada.Environment_Variables do not currently have Containers
>> associated with them, so perhaps an argument can be made that they
>> should be Iterators, rather than concoct a Container type so that
>> Iterable container syntax can be used.
>
> I don't see it as concocting a Container type; it's an Iterable
> type. Containers happen to be Iterable.
>
> It's unfortunate (but understandable!) that 4.1.6 and 5.5.1, .2 use
> container-related language.

I think there's a lot to be said for consistency. If users see that they
can iterate over directories, won't they be surprised and disappointed
to find that they have to use the clumsier 'in' form?

The implementer might be happier with a Container-ish object to support
the 'of' form, but surely the users won't care? It's all a black mystery
to them anyway (and quite right, too).

I had fun with my Date_Iteration example to support the 'of' form
without an extra type; the extras needed are the aspects on Date_Set and
the function Element.

   type Date_Set is new Iterator_Interfaces.Forward_Iterator with private
   with
     Constant_Indexing => Element,
     Default_Iterator => Iterate,
     Iterator_Element => Ada.Calendar.Time;

   function Element (Set : Date_Set; C : Cursor) return Ada.Calendar.Time;

(Date_Set is acceptable to GNAT but not to emacs ada-mode, which gets
thoroughly confused)

I must say I got quite confused about what the second parameter of
Element should be until I read ARM5.5.2(13).