ST6RI-830 Global scope notation (KERML_-101)

[TheKorpos]

Implement the resolution to the following issue, as approved in KerML FTF2 Ballot 5:

• KERML_-101 Global scope notation

This resolution extends the qualified name notation in KerML and SysML to allow it to optionally have the global scope qualifier $ as its initial segment, as in $::A::B::C. Resolution of the remainder of such a qualified name then begins in global scope, rather than in the local scope in which the qualified name is parsed. This can be particularly useful for accessing a library package that would otherwise be hidden be a local package with the same name.

For example, in the following model, the use of the global scope notation means that Requirements::FunctionalRequirementCheck resolves to the appropriate element of the library package Requirements, which would otherwise be hidden by the containing Requirements package.

package UserModel {
    package Requirements {
        requirement r1 : $::Requirements::FunctionalRequirementCheck;
        ...
    }
}

Changes

org.omg.kerml.expressions.xtext

• Updated the QualifiedName production in KerMLExpressions.xtext to optionally allow a global scope qualification $::.

org.omg.kerml.xtext.naming

• Updated KerMLQualifiedNameConverter to handle globally-scoped qualified names.

org.omg.kerml.xtext.scoping

• Updated KerMLScope and KerMLGlobalScope to resolve globally-scoped qualified names.
• Note that, since names are not required to be unique in the global namespace, it is possible for a globally-scoped qualified name to be ambiguous. If a globally-scoped qualified name can be resolved entirely within the context resource of the qualified name, then this will be preferred over a resolution to an element in another resource. (This is an implementation choice not determined by the specification.)

org.omg.sysml.util

• Updated ElementUtil.parseQualifiedName to handle global scope notation.

[seidewitz]

Unfortunately, it is not sufficient to represent a globally-scoped qualified name like $::A::B as simply an Xtext QualifiedName with an initial segment of "$". That is because '$'::A::B is also a legal qualified name, but, in this case, '$' is an actual name, not the global scope qualifier. Thus:

package A {
    package '$' {
        package A {
            part def B; // The qualified name resolves here...
        }
    }
    part def B { // ... not here.
        part x : '$'::A::B;
    }
}

I have revised the implementation to use a new GlobalScopeQualifiedName to represent a globally-scoped qualified name. I also updated the KerML Xpect tests so they also include qualified names that start with '$', to check that these now also resolve correctly (which they did not before). The name resolution for a globally-scoped qualified name remains essentially the same, however.

Please review.

[seidewitz]

@TheKorpos
I realized there is a much simpler way to do this: just use a specific string to represent the GLOBAL_SCOPE_SYMBOL as the first segment, and check for this using == rather than equals. This work as longs as we do not turn on the option to intern segment strings.

I have implemented this option on the ST6RI-830-1 branch. Please review, and, if you concur, I will move it to he ST6RI-830 branch.

[TheKorpos]

@seidewitz

Unfortunately, it is not sufficient to represent a globally-scoped qualified name like $::A::B as simply an Xtext QualifiedName with an initial segment of "$". That is because '$'::A::B is also a legal qualified name, but, in this case, '$' is an actual name, not the global scope qualifier.

Oh yes, I forgot that '$'::A::B becomes $::A::B during qn conversion. Thank you for the fix.

check for this using == rather than equals

This sounds like a pretty good idea and it is much simpler. Usually I'm a little bit worried using static fields like this. I have seen some nasty bugs where the same class was loaded multiple times in multi-threaded environments. I performed a smoke test in Eclipse and the instance is the same across threads so this is probably fine in our case. We'd also have to be careful how we (deep) copy qualified names and how we construct them moving forward.

I think prefer the first version still. It is more explicit aobut this capability and feels more correct to me but if you really like the simpler solution I don't see any imminent issues with it.

[seidewitz]

I decided to go with the simpler approach. However, I revised QualifiedNameUtil to abstract the representation of globally scoped qualified names. So, if we decide to switch back to the other approach, we can do that without any change to the scope code.

I have pushed the other approach (using GlobalScopeQualifiedName) to branch ST6RI-830-2 and force-pushed ST6RI-830 to be the same as ST6RI-830-1 with the simpler approach.