Issue 15277: current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit (kdm-rtf) Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com) Nature: Uncategorized Issue Severity: Summary: The current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit and to a certain extent ParameterUnit and StorableUnit. The issue is that some of the kind enumeration are tied to a class but in reality can apply in other places and that those enumeration are single valued where in real life usage we would need to often specify more than one value. Some concrete example: 1- ClassUnit (and InterfaceUnit) supports no modifiers (or kind enumeration in KDM speak). This issue was raised in 2006 and never addressed. How can we, without resorting to stereotypes, which are not very interoperable, describe a Java class that is “final public” or “static” 2- MethodUnit has a MethodKind but it has no ExportKind which would be a start to try to capture a Java method like “final protected” (also needs multi-value) 3- ParameterUnit has a ParameterKind but it again has no ExportKind. So another example, your Java method parameter that is declared as “final” (or is that an “ImportKind”) 4- MemberUnit represent for example Java field class member (JLS names). There we have ExportKind but like other places for Java modifiers it would be missing “static”, “transient”, “volatile” and a way to express “default”, unless we agree that it is in force if none of public, private or protected is specified. But we should be able to easily support a field declaration such as: “private static final String CONST1 = “xx”; “ I am not sure what the best approach is here in all regards. First I think we must change the cardinality to support multiple “modifiers” for the same “unit”. We also need to look if we want to simply expand the ExportKind and move it to the ComputationObject class instead of being at the MemberUnit level. That obviously expands the classes that can make use of it, but it addresses most of the issues, except for the ClassUnit and InterfaceUnit which are children of DataType Resolution: deferred to next RTF Revised Text: Actions taken: June 7, 2010: received issue Discussion: End of Annotations:===== ubject: KDM Issue Date: Sat, 5 Jun 2010 12:44:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KDM Issue thread-index: Acn1QeFXXIonDPbaRv6p7WO/0xqjsEO2Mk2Q From: "Alain Picard" To: "Nikolai Mansourov" Cc: , "Juergen Boldt" X-SpamInfo: helo-dns, Hi Nik (and KDM Team) Please open an issue regarding the following: The current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit and to a certain extent ParameterUnit and StorableUnit. The issue is that some of the kind enumeration are tied to a class but in reality can apply in other places and that those enumeration are single valued where in real life usage we would need to often specify more than one value. Some concrete example: 1- ClassUnit (and InterfaceUnit) supports no modifiers (or kind enumeration in KDM speak). This issue was raised in 2006 and never addressed. How can we, without resorting to stereotypes, which are not very interoperable, describe a Java class that is .final public. or .static. 2- MethodUnit has a MethodKind but it has no ExportKind which would be a start to try to capture a Java method like .final protected. (also needs multi-value) 3- ParameterUnit has a ParameterKind but it again has no ExportKind. So another example, your Java method parameter that is declared as .final. (or is that an .ImportKind.) 4- MemberUnit represent for example Java field class member (JLS names). There we have ExportKind but like other places for Java modifiers it would be missing .static., .transient., .volatile. and a way to express .default., unless we agree that it is in force if none of public, private or protected is specified. But we should be able to easily support a field declaration such as: .private static final String CONST1 = .xx.; . I am not sure what the best approach is here in all regards. First I think we must change the cardinality to support multiple .modifiers. for the same .unit.. We also need to look if we want to simply expand the ExportKind and move it to the ComputationObject class instead of being at the MemberUnit level. That obviously expands the classes that can make use of it, but it addresses most of the issues, except for the ClassUnit and InterfaceUnit which are children of DataType. Thanks Alain Alain Picard Benchmark Consulting apicard@benchmarkconsulting.com www.benchmarkconsulting.com CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you.