* 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 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: 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 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