Sorry, Eran, I'm just catching up with email backlog now...
The reason for this funny test is that OMSourceElementImpl previously would break when methods were added to the base OMElementImpl class without any handling in OMSourceElementImpl. The test enforces a requirement that all methods of OMElementImpl are overridden in OMSourceElementImpl so that anyone who changes the base class contract has to also change the subclass. This does add a minor overhead, but I felt the benefits of enforcing conscious handling were worth the cost.
- Dennis Eran Chinthaka wrote:
Hi, There were some methods in OMSourceElementImpl which were merely calling its super methods. So I removed them. But there was a test written (OMSourceElementImplTest) to test whether OMSourceElementImpl had overridden all the methods in OMElementImpl, which is bit unusual in every sense to me. 1. When a class extends from another class, there is no requirement to override *all* the methods of the super class. 2. Some methods were just calling the super method. Dennis (IIRC, you wrote this test), can we please change the test case and remove those methods from OMSourceElementImpl? Thanks, Chinthaka
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
