Re: AIs for Ada extensions

["Robert I. Eachus" <rieachus@attbi.com>]

Alexander Kopilovitch wrote:

> It seems to be an unfortunate collision that multiple new packages should be
> proposed when Abstract Interfaces still aren't established firmly.
> It is highly likely that some packages (for example, Data structures
> components) may look significantly better if they can use Abstract Interfaces.
> But one can't expect "widely used" prototype interface-based packages for
> standartization until Abstract Interfaces went into practice in Ada.
> So, perhaps, standartization of packages that can significantly benefit
> from Abstract Interfaces should be delayed, and follow the Core standard
> after year or two.

I personally don't see any conflict.  The interface AI will allow easier 
bindings to C++ and Java.  But in Ada, mix-ins are a better abstraction 
IMHO for containers.  The advantage is that you can easily put objects 
in a container even if the original declarer of the type/class had no 
idea that they would be put in a container.  For example:

with Ada.Containers.AVL_Tree;
generic
   type Member is private;
   with function Index(E: Element) return String;
   Null_Entry: Member;
package Dictionaries is
   type Dictionary is limited private;
   function Lookup (Key: in String) return Member;
   function Add (M: in Member);
   ...
private
   type Dictionary is new Ada.Containers.AVL_Tree(Member,...);
   ...
end Dictionaries;

(No arguments about how to better do this, please.  This is just an 
expository example)

Notice that using mix-in containers, the type Member doesn't have to 
"know" that it could be added to a Dictionary.  The actual dictionary 
entry will in effect be a child of Member and AVL_Trees.Tree.  But 
Member doesn't even have to be a tagged type...