Re: class wide iterable (and indexable)

[George Shapovalov <gshapovalov@gmail.com>]

> Vectors support both indexing by an integer and reference via a cursor. 
> Usually, the List container is a better example for cursor operations 
> because it doesn't have the confusion of (direct) indexing involved.
Ah, right, that Ada gem I initially read was indeed operating on linked lists. This is why it only implemented one method. But I needed the indexing too in my case, which is attached via different aspects. So it all seemed to correspond so far and even work, as long as I did not try to do an "of-loop" over class-wide var (derived types worked fine).


> Because that would substantially harm ease-of-use. You'd have to write 
> multiple instantiations to create any container. It's annoying enough (to 
> some, at least) to have to write one.
Well, I rather consider an extra line of (typically elementary) code a small price for versatility, but then apparently opinions vary a lot on this one :). 
But the next point is more essential:

 
> Besides, interfaces are (nearly) useless (and especially so for this sort of 
> usage, where some part has to be generic). They add a lot of runtime 
> overhead that doesn't actually get used in real programs.
Really? I did not consider this. I thought there would be no extra overhead, as the compiler should be able to select appropriate constructs as needed and optimize away with higher -OX. But indeed, in case of generics it would likely produce extra code blobs.. Oh, well, looks like I may be better off with a more simplistic design, using getters/setters and iterating over the provided index type (which is needed there anyway). Looks like that would be more efficient with generics, even though less elegant. Those extra get/set qualifiers instead of direct indexed access look a bit annoying :). But this is really a minor issue. And at least I learned a thing or two about inner gnat workings on the way :).

> Perhaps if Ada allowed multiple controlling parameters of different tagged 
> types, then there might be more use.
Funny that you mention this one. That was my thought exactly at one (completely unrelated) point - that unlike most other languages, Ada has the syntax that could naturally allow multiple controlling parameters, and that could be a really powerful type composition feature.. A pity this was not done so, that would be a fun feature. But then I do realize that it takes a special kind of thought organization (more pure math than typical procedural idiom most programmers follow) for the developer to feel comfortable with such a feature. With most other common languages not having even a provision to formulate such a structure, most developers would be at a loss to comprehend what is even proposed in the standard I am afraid (at least from what I could observe). So I can see why this was not seriously considered. Plus that would give a huge potential for abuse - just think of all the possible combinations multiplying complexity, having to turn simple dispatch tables into multidimensional (and very sparse) arrays..

Btw, I'd rather say that this, and not the (not so evident) observation of extra overhead is the main reason for:
> For example, we 
> did do what you suggest for the queue containers. Irrelevant thought: that's 
> probably why I have yet to hear of anyone actually using one of them. :-) 
That, and (more essentially) that the standard Ada.Containers are sufficient for most situations, as you point out elsewhere.


> But with the existing Ada rules, 
> interfaces can only be useful if the profiles are fixed (non-generic) and 
> are still reusable -- that doesn't happen that often.
Why? 
Besides the optimization issues, which are invisible to end user and often are not so critical, I fail to see how generics would affect logical structure of the program in this case. Besides linking various type hierarchies together, interfaces are good for containing common code that does not care about specific data storage details. How generics complicate the issue? (at the level of program logic, not underlying code - most apps away from critical domains do not care about 2x size or loss of 10% time efficiency away from critical loops, if that allows to reuse well tested code). In fact it seems to me that generics fit very well with such development model..