Issue 19816: Unspecified handling of imports without access/extends (qvt-rtf) Source: (, ) Nature: Enhancement Severity: Significant Summary: For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit. The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit). Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports. Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior. Resolution: Unspecified handling of imports without access/extends For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit. The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit). Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports. Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior. Discussion Following some off-JIRA correspondence, the original issue is clearer and simpler. The 8.2.1.4 words say that ImportKind has only two possibilities. But the words and model omit a [1] multiplicity or defaultValue so that null is a third possibility. The grammar also permits a missing ImportKind. So as suggested we could introduce a third null semantics, or define one of access/extends as the default. I see no benefit in a third semantics. "extends" is a very serious mutating activity, not a default. "access" is harmless and non-mutating. Hardly AST clutter. If the user didn't want the names the user should not have specified an import. Let "access" be the default. Revised Text: In 8.2.1.4 ModuleImport The semantics of the library import. Possible values are access and extension. access is the default. In the QVTo model change ModuleImport.kind lowerbound to 0..11 and defaultValue to unspecifiedaccess. Consequently show the [1] multiplicity in 8.2.1.4 and Figure 8.1. Actions taken: July 9, 2015: received issue December 22, 2015: Resolved March 29, 2016: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 09 Jul 2015 04:58:07 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Christopher Gerking Employer: Heinz Nixdorf Institute, University of Paderborn mailFrom: christopher.gerking@upb.de Terms_Agreement: I agree Specification: Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification Section: 8.2.1.4 ModuleImport FormalNumber: formal/15-02-01 Version: 1.2 Doc_Year: 2015 Doc_Month: February Doc_Day: 01 Page: 85 Title: Unspecified handling of imports without access/extends Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: nb-sch-fs782-1.cs.uni-paderborn.de Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36 Time: 04:58 AM Description: For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit. The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit). Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports. Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.