Community
Participate
Working Groups
EG (12/20/99 6:52:43 PM) In VAJ you can execute a class that doesn't implement all methods of an interface. You get an exception once an unimplemented interface method is called. In LeapFrog you get an exception when you try to instantiate such a class. NOTES: EG (2/23/00 8:42:50 PM) moved to LFCOM for consideration in EBAF PM (9/13/2001 11:59:26 AM) This would require a problem type would be generated default (problem) implementations for missing abstract methods... Doable.
Ask KJ for how to get the set of abstract methods to implement.
To solve this problem, we need to create a problem method for each unimplemented abstract method instead of creating a problem type. Need to see how to add these methods.
PRODUCT VERSION: EG 324
Addind the abstract problem method is not a problem. It is more difficult to know how to map the error message on the right problem method. Let's consider you have a class X that implements an interface I. This interface defines two methods signatures (foo()V and bar(I)I). None of them are actually implemented by X. Then two problems will be raised to report these two errors and the class file will try to generate a problem type. The problem is to find out which problem should be reported for each problem method instead of reporting the two problems on the default constructor. Reporting the problem on the default constructor or the constructor without any parameters prevents from instanciating on object of class without getting an error.
I need to add a specific support in the ClassFile in order to be able to report this missing implementation error. In this case we don't have any method declarations that can match the astract method binding. So we cannot add a problem method that contains local variable attributes.
Not only a support needs to be added for the missing abstract methods, but the flow analysis and the code generation needs to be done on the constructors. Otherwise the constructor throws an error even if all errors on missing abstract methods have been moved to the new problem methods. I need to see how to proceed with other methods and at the end add the problem methods for missing abstract methods.
One solution could be to create fake method declarations for missing abstract methods. This would allow the problem to be reported on these method declarations instead of the type declaration. Then we would not create a problem type, but simply problem methods for each missing abstract methods.
Fixed and released. Regression tests added (see ConformTests.test159/test160).
*** Bug 12809 has been marked as a duplicate of this bug. ***
