Re: procedural vs object oriented

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 27 Apr 2006 03:42:10 -0700, Ludovic Brenta wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 27 Apr 2006 07:22:21 +0200, Ludovic Brenta wrote:
>>> According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
>>> software, because the uncertainty inherent to dynamic dispatching
>>> hinders certification.  Is someone on this newsgroup in a position to
>>> give a counter-example?
>>
>> Can't tell about avionics, but what uncertainty of dynamic dispatching is
>> meant? Or, maybe, "certification" is the context of? Then which
>> certification, according to which criteria?
> 
> 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),

(I have an impression that it will not be true in Ada 200Y.)

> but there is uncertainty about which one it is.

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?

> DO-178B does not prohibit dynamic dispatching; it only requires that
> the program be completely deterministic, and it requires the software
> developers to provide reasonable proof that the program is indeed
> deterministic.

Very sensible, IMO.

> If you use dynamic dispatching in a program, you must therefore prove
> that you know precisely which subprogram you call each time you execute
> the dispatching call. At DO-178B level A, you must also prove that the
> machine code in the executable program dispatches correctly and in a
> deterministic way, in bounded time and memory conditions. This
> additional burden of proof is on the developer. That's what I meant
> when I said that dynamic dispatching hinders certification.

OK, it could make things more difficult.

>> Talking about uncertainty in general, what about "inherent uncertainty" of
>> a procedure call? Can you tell which procedures will be called and when at
>> run time? If you can then, you can also do it for dispatching calls. Are
>> generic bodies more certain? With "with function "*" (Left, Right : Foo)
>> return Foo"? Really?
> 
> 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. Provided, that there is nothing uncertain in how
dispatching works or what potential targets do.

> When you instantiate a generic, you also know exactly which subprogram
> you pass as a parameter. Again there is no inherent uncertainty here.

My question was about the body. If you are required to check each
instantiation, then it effectively means that you cannot certify the
generic body itself, only concrete instances of. This is no different from
a dynamically polymorphic body. Both forms of polymorphism save work
exactly because you don't need to care about specific instances. If the
certification procedure does not play with, there is little gain.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de