EDIT: Sorry for the wonky formatting first time poster and the editor is a little secretive about what its doing [:P]
I am getting an error when trying to implement an interface that is using ENUM's and I an not having much luck as to finding out why...
I have an interface that looks like:
using Progress.Lang.*. using Business.Library.Results. using Business.Library.Instrumentation.Notification.ETransportationStatus. using Business.Library.Instrumentation.Notification.ENotificationTransportTypes. interface Business.Library.Instrumentation.Notification.INotificationTransportMethod: define public property transportType as ENotificationTransportTypes no-undo get. set. define public property transportStatus as ETransportationStatus no-undo get. set. define public property results as Results no-undo get. set. /*------------------------------------------------------------------------------ Purpose: Notes: ------------------------------------------------------------------------------*/ method public Business.Library.Results Send( ). end interface.
#######################################################################################################
...then I try to implement the interface in an EmailNotification class (all this code is generated by PDSOE):
#######################################################################################################
using Progress.Lang.*. using Business.Library.Instrumentation.Notification.INotificationTransportMethod. block-level on error undo, throw. class Business.Library.Instrumentation.Notification.EmailNotification implements INotificationTransportMethod: define public property results as Results no-undo get. set. define public property transportStatus as ETransportationStatus no-undo get. set. define public property transportType as ENotificationTransportTypes no-undo get. set. method public Business.Library.Results Send( ): undo, throw new Progress.Lang.AppError("METHOD NOT IMPLEMENTED"). end method. end class.
#######################################################################################################
When I try to syntax check the class I get this error:
Syntax Check:
The data type of property 'transportType' does not match the same-named property
in abstract class or interface
'Business.Library.Instrumentation.Notification.INotificationTransportMethod'
I've been staring at this problem for way too long and not making much ground. Hopefully its something simple that I am just missing.
It appears to have to do with the ENUM's because If I change them to character data-types I dont get the error. I just dont get what I am doing wrong with them.
SOLVED: I added the 'using' statements for each and that did the trick!
SOLVED: I added the 'using' statements for each and that did the trick!
When I've run into issues like this it was due to stale r-code somewhere in the PROPATH. A project clean / build usually solves it, or deleting the r-code.
The message is misleading. Actually the compiler is not able to resolve the type of "ENotificationTransportTypes", because it is not fully qualified and there is no USING.
But when you implement an interface, instead of telling you that it cannot resolve the type, the compiler jumps straight to the message that it cannot find the implementation of something required by the interface or that the implementation does not match.
Hi Simon:
Can you log this issue with Technical Support? This is a good example of an improvement we can make to the compiler.
Thanks
Hi Evan
I logged case 00527611 for this, with an example.
Thanks
So I assume you are just hoping for a better error message. And of course this is not specific to Enums. It would happen for the return type of any method implemented for an interface, for example.
[mention:644b32c9259141d2b1b21a2813ab7487:e9ed411860ed4f2ba0265705b8793d05] Tech Support logged OCTA-18481 for this.
[mention:04fbfb2e92784123a464ff2aade602b1:e9ed411860ed4f2ba0265705b8793d05]
Correct. The compiler simply validate things in the wrong order. The problem is not limited to missing USING, but also occurs when the type name is misspelled, even for the primitive types. If the interface wants a CHARACTER and you define it as CAHRACTER you will get the problem the original poster experienced.
In these cases, when you remove the IMPLEMENTS phrase, thus not implementing the interface, you will typically get error "Invalid datatype specified: <type>. Specify a datatype such as 'character' or the name of a class. (5638)" (and error 196, though I believe 196 is redundant) on the relevant line.
As soon as you have the IMPLEMENTS phrase, however, you will be pointed to the end of the file and receive either of:
- Interface '<Interface-Type-Name>' requires method '<method-name>' to be implemented by class ''. The method is either missing or has mismatched parameters. (12942)
- The data type of property '<propname>' does not match the same-named property in abstract class or interface '<name>'. (14753)
That is confusing, since the implementation is / seems to be, correct. I've seen many people copy the method or property definitions from the interface to the class in their attempts to resolve that, of course with no success, since the actual problem is that the data type is not recognized.
The compiler should first raise error 5638 and should not even try to check if the interface was implemented correctly before those are resolved, as it is simply not possible to do that as long as there are "invalid" data types present.
I attached a very elementary but functional example and steps to reproduce in the support case (00527611).
I've just discovered a third case which I missed.
If the return type is not known, you would normally also receive error 5638, but as soon as an interface is involved, you receive:
- Method '<method-name>' in interface definition '<interface name>' returns '<name-space-and-type-name>', but the method implementation returns '<type-name-with-no-namespace>'. (12951)
This is however not as confusing as with property and parameter types, since you should spot the difference between '<name-space-and-type-name>', which is normally long, and '<type-name-with-no-namespace>', which is typically much shorter.