Assignment action not able to find feature of redefined "this"

Syside
,
1

Hey all, I got this example of an assignment action from The SysML v2 Book.

part def MissionCounter { 
    attribute completedMissions : ScalarValues::Integer := 0; 
    action completeMission { 
        :>> this : MissionCounter; 
        assign this.completedMissions := completedMissions + 1;
    } 
}

In SysIDE it fails with this error. Any ideas?

image
image650×147 9.51 KB

2

Hi,

the scoping can sometimes be weird/unexpected in SysML. In this case, this is resolved relative to the parent AssignmentActionUsage and not completeMission as one would expect. It is likely that the specification just did not find all the weird edge cases with the deep hidden layers the syntax creates.

image
image2544×1290 440 KB

We are also aware of a similar issue with satisfy <requirement> by self where self would be resolved to the SatisfyRequirementUsage itself. Standard library seems also aware of this SysML-v2-Release/sysml.library/Systems Library/Views.sysml at 8bae63195678842fe73a1c58a098139cb927f2bd · Systems-Modeling/SysML-v2-Release · GitHub.

This likely extends to all other similarly constructed elements that allow declaring special members with references.

3

Hi Daumantas,

That makes sense, thank you for the info. I also just found https://cst.syside.app/, what an awesome tool. I am curious how you can tell from the tree which parent “this” is being resolved in.

The code you linked hints that it might be possible to specify exactly which parent should be used. I am not sure how to do that but will look into it, and update if I find the answer! Thank you.

4

I am curious how you can tell from the tree which parent “this” is being resolved in.

It is typically the owning namespace of the referent with some exceptions:

  • chained references (following a .) are resolved relative to the previous segment and nothing else
  • expression trees are often, but not always according to the current spec, unwrapped completely
  • declaration specializations go up a level to the owning namespace of the specific type

These are the most common exceptions but as you have seen they do not cover all the expected cases, at least at this time.

There is no way to specify where the name resolution starts from, it is all deterministic based on name resolution rules.