re: OO vs procedural

re: OO vs procedural

[Ed Falis]

There are two papers on AdaCore's website that go into some of the issues  
with certification of applications containing dispatching:

http://www.adacore.com/2006/03/08/certification-object-orientation-the-new-ada-answer/
http://www.adacore.com/2006/03/30/safety-security-and-object-oriented-programming/

- Ed

Re: OO vs procedural

[kevin cline]

In the second paper, they give this example:

type Alert is abstract tagged record
  ...
end record;
procedure Handle(A: Alert);

type Flaps_Alert is new Alert with record
 ...
end record;

procedure Handle(A: Alert) is
begin
  -- Code common to all alerts
  Log(A);
end Handle;

procedure Handle(A: Flaps_Alert) is
begin
  Alert(A).Handle; -- do common processing
  ... -- flaps specific processing
end Handle;

The authors then point out a describe a potential pitfall of this code
-- that a derived type implementation may fail to call the base
implementation.  This is true.  The authors fail to point out that this
possibility could have been prevented by correct base class design.

I also fail to understand why this error is hard to test, but perhaps I
do not understand S3 testing methods.  I would have expected that a
failure of a derived type X_Alert to call the base type Handle method
would have been caught by a unit test of X_Alert, when it was observed
that after calling X_Alert.Handle, no logging occured.

I would also expect that the error would be easily detected through any
formal verification process, since the erroneous Handle method would
not meet the 'Logging occured' postcondition.

Re: OO vs procedural

[Ludovic Brenta]

"kevin  cline" <kevin.cline@gmail.com> writes:
> In the second paper, they give this example:
>
> type Alert is abstract tagged record
>   ...
> end record;
> procedure Handle(A: Alert);
>
> type Flaps_Alert is new Alert with record
>  ...
> end record;
>
> procedure Handle(A: Alert) is
> begin
>   -- Code common to all alerts
>   Log(A);
> end Handle;
>
> procedure Handle(A: Flaps_Alert) is
> begin
>   Alert(A).Handle; -- do common processing
>   ... -- flaps specific processing
> end Handle;
>
> The authors then point out a describe a potential pitfall of this code
> -- that a derived type implementation may fail to call the base
> implementation.  This is true.  The authors fail to point out that this
> possibility could have been prevented by correct base class design.
> 
> I also fail to understand why this error is hard to test, but perhaps I
> do not understand S3 testing methods.  I would have expected that a
> failure of a derived type X_Alert to call the base type Handle method
> would have been caught by a unit test of X_Alert, when it was observed
> that after calling X_Alert.Handle, no logging occured.
>
> I would also expect that the error would be easily detected through any
> formal verification process, since the erroneous Handle method would
> not meet the 'Logging occured' postcondition.

Of course, what you say is true - good unit testing or good peer
review will catch the error, and the formal verification process will
document how the error was found, corrected, and verified to be
corrected.  But, by that argument, "any good programmer with a good
process can write perfect software in any language, even assembly
language".

The point is to help the compiler catch the error automatically,
before the first unit test is written and before any peer review takes
place.  Compile-time checks are why we (in avionics) use Ada in the
first place.  In other industries, people also like the run-time
checks, which help later, i.e. during testing.

-- 
Ludovic Brenta.

Re: OO vs procedural

[Dmitry A. Kazakov]

On Thu, 04 May 2006 22:21:37 +0200, Ludovic Brenta wrote:

> "kevin  cline" <kevin.cline@gmail.com> writes:
>> In the second paper, they give this example:
>>
>> The authors then point out a describe a potential pitfall of this code
>> -- that a derived type implementation may fail to call the base
>> implementation.  This is true.  The authors fail to point out that this
>> possibility could have been prevented by correct base class design.
>> 
>> I also fail to understand why this error is hard to test, but perhaps I
>> do not understand S3 testing methods.  I would have expected that a
>> failure of a derived type X_Alert to call the base type Handle method
>> would have been caught by a unit test of X_Alert, when it was observed
>> that after calling X_Alert.Handle, no logging occured.
>>
>> I would also expect that the error would be easily detected through any
>> formal verification process, since the erroneous Handle method would
>> not meet the 'Logging occured' postcondition.
> 
> Of course, what you say is true - good unit testing or good peer
> review will catch the error, and the formal verification process will
> document how the error was found, corrected, and verified to be
> corrected.  But, by that argument, "any good programmer with a good
> process can write perfect software in any language, even assembly
> language".

No, I don't think that was the point.

I agree with Kevin. IMO the designs the author presented are obviously not
equivalent. So the paper is quite misleading in that respect. More
detailed:

SP version goes:

procedure Handle (A: Alert) is
begin
   CH; -- Code common to all alerts
   Log (A); -- alerts are logged here
   case A.Device is
      when Flaps =>
         FH; -- Flaps specific handling
      when Rudder =>
         RH; -- Rudder specific handling
   end case;
end Handle;

As an OO equivalent he presents Handle declared as a primitive procedure.
This is *not* an equivalent design pattern. An equivalent one would be to
use a class-wide Handle dispatching to device-specific handling:

procedure Handle (A: Alert'Class) is -- Class-wide
begin
   CH; -- Code common to all alerts
   Log (A); -- alerts are logged here
   Do_Specific (A);-- Specific handling
end Handle;

procedure Do_Specific (A : Flaps_Alert); -- Primitive

procedure Do_Specific (A : Rudder_Alert);

Now, Log is perfectly enforced as in SP version. (*)

The fallacy is that the problem of "extensible subprograms" is not specific
to OO. It is to Ada design. Furthermore, structured programming does not
respond this problem either.

-----------
*  BTW, author is silent about what would happen if some idiot called Log
from FH path. Observe, that Ada's OO design provides an additional *safety*
here: no implicit redispatch allowed. So if Log were declared class-wide
(as it should), then Ada compiler wouldn't let our idiot to call it from
Do_Specific, without an explicit type conversion!

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

Re: OO vs procedural

[Brian May]

>>>>> "kevin" == kevin cline <kevin.cline@gmail.com> writes:

    kevin> The authors then point out a describe a potential pitfall
    kevin> of this code -- that a derived type implementation may fail
    kevin> to call the base implementation.  This is true.  The
    kevin> authors fail to point out that this possibility could have
    kevin> been prevented by correct base class design.

What is the potential error in the above code? I think I must have
missed it.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: OO vs procedural

[Stephen Leake]

"kevin  cline" <kevin.cline@gmail.com> writes:

> In the second paper, they give this example:

I'm missing context here; what paper are you talking about?


> <snip code>
>
> The authors then point out a describe a potential pitfall of this code
> -- that a derived type implementation may fail to call the base
> implementation.  This is true.  

Right.

> The authors fail to point out that this possibility could have been
> prevented by correct base class design.

How, exactly? I've never heard this claim before.

-- 
-- Stephe