Re: What makes a procedure call 'dispatching' in Ada?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Dmitry A. Kazakov wrote:
> On Fri, 20 Nov 2009 17:00:44 +0200, Niklas Holsti wrote:
> 
>> A better analogy is code like this:
>>
>>     procedure John (X : Integer ..) is
>>     begin
>>        ...
>>        if X /= 1 then ...
>>        end if;
>>        ...
>>     end Jonh;
>>
>>     procedure Mary (...) is
>>     begin
>>        if X = 1 then
>>           John (X);
>>        else ...
>>        end if;
>>     end Mary;
> 
> This is a wrong analogy. In your example John serves all values of X.

You are not seeing the analogy that I intended. John does different 
things for certain values of X, similar to a primitive operation that is 
overridden for certain types (values of X when X is a tag).

> So when you call it with the value 1 it is not like dispatch, which
> chooses a body for just one tag.

The test "if X /= 1" in John is analogous to one dispatch, and the test 
"if X = 1" in Mary to another (perhaps it would have been clearer if the 
latter had been "if X > 2", or some other pair of less correlated 
checks). My point is that it is quite normal and valid to make several 
tests of the same value, as long as the tests are not redundant.

>> Yes, there is a double check of X, but no, it is not a redundant check.
> 
> But with dispatch the check is redundant.

Obviously it is not, because the program behaves quite differently with 
redispatching than without it.

I grant you that for every program that uses redispatching there is an 
equivalent program that does not redispatch and computes the same thing. 
But I, personally, seem to find the redispatching program simpler to 
construct and understand. I also think it is usually shorter, with less 
almost-duplicated code.

I won't comment any more on the "object identity" question -- it becomes 
too philosophical for me (your reference to Plato motivates the use of 
this word :-). Redispatching is a well defined feature of current Ada 
that I find useful and not dangerous -- so far, at least.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .