Re: procedural vs object oriented

["Alex R. Mosteo" <devnull@mailinator.com>]

Ludovic Brenta wrote:
> Dmitry A. Kazakov wrote:
> 
>>On 27 Apr 2006 03:42:10 -0700, Ludovic Brenta wrote:
>>
>>>Dynamic dispatching, by definition, means that you don't know which
>>>subprogram you call at run-time. The compiler guarantees that the call
>>>will succeed (i.e. that there exists a subprogram to dispatch to),
>>>but there is uncertainty about which one it is.
>>
>>(I have an impression that it will not be true in Ada 200Y.)
> 
> 
> No, nothing changes in this respect, just synctactic sugar.
> 
> 
>>OK, but this is the same uncertainty as in X + 1. You don't know X, so the
>>result selected by "+" is uncertain (to you.) Are programs using "+"
>>certifiable?
> 
> 
> Yes, programs using "+" are certifiable. To obtain the certification,
> you prove that X+1 is within range and that the operation does not
> raise an exception. Ada's type safety features go a long way to help us
> there, so we only have to test for a few boundary cases. SPARK takes
> that to its logical conclusion, i.e. static proof.
> 
> 
>>>A static procedure call has no uncertainty: when you read the program
>>>source, you know exactly which subprogram is called, even in the
>>>presence of overloading.
>>
>>Well, no:
>>
>>if Read (File) then
>>   Foo;
>>else
>>   Bar;
>>end if;
>>
>>The uncertainty of a dispatching call is one of the context, exactly as in
>>the example above.
> 
> 
> Nothing in your example is uncertain. Whatever path execution takes,
> you know exactly what's happening.
> 
> 
>>Provided, that there is nothing uncertain in how
>>dispatching works or what potential targets do.
> 
> 
> But with compiler-provided dynamic dispatching, there *is* uncertainty
> as to how dispatching works and what the targets are.

This is something I'm not getting in this discussion. Provided that you 
know all derived classes, you know all possible dispatchings and you can 
validate all for correctness and time the worst one. How's this 
different than evaluating all branches in a case?

It's true that you don't have the information at the calling point, but 
you have it elsewhere.

>