Re: point by point advantages of Ada

["Randy Brukardt" <randy@rrsoftware.com>]

James S. Rogers wrote in message ...
>"David Thompson" <david.thompson1@worldnet.att.net> wrote in message
>news:24oS9.30853$p_6.2594702@bgtnsc04-news.ops.worldnet.att.net...
>> Ada uses return type to resolve overloading (at compile time), but
>> not to dispatch (possibly at run time).  (C++ and Java do neither.)
>
>Quoting from "Ada as a Second Language" by Cohen:
>"If a primitive function of a type T has a result of type T, but no
parameters
>of type T or access T, a call on the function can be either
nondispatching or
>dispatching depending on the context."
>
>This is clearly more than simple overload resolution.

But it's not quite dispatching on the tag of the result (which you can't
know). But it is dispatching on the tag of result that you need. Here is
a quick example of it:

      type T is tagged ...
      function Build_It (I : in Integer) return T; --(1)
      procedure Copy (Target : out T; Source : in T);

      type NT is new T ...
      function Build_It (I : in Integer) return NT; --(2)
      type NNT is new T ...
      function Build_It (I : in Integer) return NNT; --(3)


      procedure Do_Something (Obj : in out T'Class) is
      begin
           ...
           Copy (Obj, Build_It(10)); -- Here is the dispatching on
result type.
           ...
      end Do_Something;

This call to Copy is dispatching. The first parameter is dynamically
tagged, and the second is tag-indeterminate. Since Build_It has no
dispatching parameters, it takes the tag to dispatch on from the
enclosing call of Copy (RM 3.9.2(18)). That means that if the tag of Obj
is T, then Build_It (1) is called, if Obj is NT, then Build_It (2) is
called, and so on.

This is convinient for constructor functions, because it means that the
right one will automatically be called in a dispatching context. It also
means that the tag check (which insures that both operands have the
correct tag) can't fail for this call, so Constraint_Error can't be
raised by this call. OTOH, I've never actually used this capability in
practice.

                 Randy Brukardt.