Update concerto-analysis rules to analyse aliased imports

[ekarademir]

Related analysers are probably these

• Properties
• Class declarations that extend an imported type
• Import statements

[ekarademir]

• Is aliasing just a syntactic change? So should it be ignored in analysis?
• Or should it at least cause a patch change

Are the following the same

import com.example.foo@1.0.0.{Bar}

concept Animal {
  o Bar leg
}

import com.example.foo@1.0.0.{Bar as baz}

concept Animal {
  o baz leg
}

[salujajaskeerat]

The current version of concerto-analysis only analyses the semantic structure of a model file. Whereas aliasing a type is only a syntactic change.

Also, there is no import factory at present.

Handling the above would require us to create an import factory.

Pros of analysing aliased imports:

• we can label the alias changes as patch changes; this would explicitly tell the user that he has made an alias change.

cons of analysing aliased imports

• aliasing a type is only a syntactic change, it does not change anything semantically

[ekarademir]

Our BDFL decided this will be a patch change.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.