Re: Is the Writing on the Wall for Ada?

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

I said:

> there is no reason to do explicit casting


Hyman Rosen wrote:

> Except when there is. These kinds of situations arise when objects are
> held in containers, passed around through various pieces of code not
> necessarily under your control, and finally handed back to your code.
> The object comes in as a pointer to some class, and the situation may
> arise when you need to know whether the object is of some other class
> type as well. The dynamic_cast will safely tell you, (almost) regardless
> of how the two classes are arranged in the inheritance hierarchy of the
> most derived type.
> 
> This is a moot point in Ada right now, since Ada just has SI. When the
> access discriminant style is used, this cross-casting is impossible
> unless you go back to the base type first, which means that code which
> in C++ would know only about the two interface types must in Ada be aware
> of the containing type as well.

No, it is not a moot point in Ada.  You can create containers for 
classwide types, and you may want to use an operation only valid for a 
subclass of that class.  But as I said:

 > If you say (using my code):

 >    Set(Some_Object, Red);  -- where Red is a value of type Color.

 > you would get exactly the same result as if you said:

 >    Set(My_Colors.Colored_Object(Some_Object), Red);

In this case if say the code was:

declare
    Some_Object: Nothing'Class := Pop(Some_Stack); -- where Nothing is my
    -- original base class and Pop is for some Stack class instantiated
    -- for Nothing'Class.
begin
    Set(Some_Object, Red);
    ...
exception
    when Constraint_Error => Put_Line("Not a member of My_Color'Class.");
    when Program_Error => Put_Line("Oops"); -- there are potential cases.
end;

Again I could do the explicit cast, but why?  The view conversion will 
raise Constraint_Error if it fails.  Actually, there might be a case 
where I wanted to walk a subtree changing colors for objects that had 
them.  Then it would be more appropriate to do:

declare
   Some_Object: Nothing'Class := Next(Some_Tree_Iterator);
begin
   if Some_Object in My_Color'Class
   then
     Set(Some_Object, Red);
   end if;
end;

With the current interface proposal, you could even say "if Some_Object 
in Colored_Object'Class..." and it would do the correct check for 
several different potential instances of Colors that are subclasses of 
Nothing.  The call on Set will work or raise Constraint_Error (or 
Program_Error) for either the interface approach or the mix-in approach.

But notice what is going on here.  In the cases where "true" multiple 
inheritance can't work, Ada resolves the ambiguity based on the 
parameter and result profile, the mix-in order, allows the user to 
directly resolve the overloading, or raises an error.  (Program_Error is 
possible in some cases, such as the call being made where the routine is 
at the wrong accessability level.  Not a problem unless you instantiate 
generics inside subprograms, and aren't careful.)  In many cases where 
other languages that support MI will barf, there is no problem in Ada. 
That was the whole point of my overloading Set and Get.  Since Ada looks 
at the whole profile when doing overload resolution, not just the name, 
you can do this and it will "just work," even though a concrete type can 
inherit dozens of Get and Set operations from different classes.
-- 
                                          Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. -- from Red Rabbit by 
Tom Clancy.