QVT13 — QVTo: access/extension default for ImportKind

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.

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.