* re: OO vs procedural
@ 2006-04-27 12:06 Ed Falis
2006-05-04 19:40 ` kevin cline
0 siblings, 1 reply; 6+ messages in thread
From: Ed Falis @ 2006-04-27 12:06 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OO vs procedural
2006-04-27 12:06 OO vs procedural Ed Falis
@ 2006-05-04 19:40 ` kevin cline
2006-05-04 20:21 ` Ludovic Brenta
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: kevin cline @ 2006-05-04 19:40 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OO vs procedural
2006-05-04 19:40 ` kevin cline
@ 2006-05-04 20:21 ` Ludovic Brenta
2006-05-05 7:58 ` Dmitry A. Kazakov
2006-05-04 22:14 ` Brian May
2006-05-05 9:18 ` Stephen Leake
2 siblings, 1 reply; 6+ messages in thread
From: Ludovic Brenta @ 2006-05-04 20:21 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OO vs procedural
2006-05-04 19:40 ` kevin cline
2006-05-04 20:21 ` Ludovic Brenta
@ 2006-05-04 22:14 ` Brian May
2006-05-05 9:18 ` Stephen Leake
2 siblings, 0 replies; 6+ messages in thread
From: Brian May @ 2006-05-04 22:14 UTC (permalink / raw)
>>>>> "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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OO vs procedural
2006-05-04 20:21 ` Ludovic Brenta
@ 2006-05-05 7:58 ` Dmitry A. Kazakov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2006-05-05 7:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OO vs procedural
2006-05-04 19:40 ` kevin cline
2006-05-04 20:21 ` Ludovic Brenta
2006-05-04 22:14 ` Brian May
@ 2006-05-05 9:18 ` Stephen Leake
2 siblings, 0 replies; 6+ messages in thread
From: Stephen Leake @ 2006-05-05 9:18 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-05-05 9:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-27 12:06 OO vs procedural Ed Falis
2006-05-04 19:40 ` kevin cline
2006-05-04 20:21 ` Ludovic Brenta
2006-05-05 7:58 ` Dmitry A. Kazakov
2006-05-04 22:14 ` Brian May
2006-05-05 9:18 ` Stephen Leake
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox