ProtocolModelProjectorRule change in rev 435

[perneto]

I just noticed that a recent change to the project method in ProtocolModelProjectorRule makes it ignore the model parameter for projection (except from pulling imports from it), and instead projects the protocol attached to the Role instance given as a parameter.

What is the reason for the change? I find it quite confusing, and possibly incorrect (what if the Role instance comes from a different protocol? Then we end up projecting another, different model).

It also makes it harder to use project() programmatically, as this forbids callers from just creating a Role instance and passing it in.

Olivier

[objectiser]

This was because the projection for a particular role should only begin at the scope within which the role is defined.

Previously I was assuming that all of the unrelated constructs, outside the scope of the role, would be 'filtered out' as part of the projection process - however (can't remember the exact issue) this was not happening - and seemed more sensible to just find the scope where the role is defined and start from there.

I agree about your last point, so will just use the supplied role to look up the role object defined within the model.

Regards

Gary

[perneto]

I'm also running into cases where the check

role.getParent() instanceof RoleList

in ProtocolProjectorImpl fails, and I see that the parent turns out to be an Interaction!

Have you had the same problem before? It's a little hard to reproduce.

[objectiser]

No haven't seen this - are you just running the projection on a model returned from the parser, or is the model generated in some other way?

[perneto]

I'm always using models created by the parser.

I ran into this problem when I was trying to understand the projector code; at a point I was thinking I needed to pass in a Role instance obtained from my model. I changed my code from this:

val role = new Role(roleName)
val projectedModel = projector.project(globalModel, role, scribbleJournal, null)

to this:

var role: Role = null
globalModel.getRoles.foreach { r =>
  if (r == new Role(roleName))
    role = r
  }
assert(role != null)
val projectedModel = projector.project(globalModel, role, scribbleJournal, null)

With the changed code, two of my unit tests are exhibiting the problem: role.getParent() suddenly becomes an Interaction instance. This is on a model created by the parser, and used by many unit tests, all of which do projection and pass, but for these two.

What's more, the Interaction instances were some that I created programmatically when doing typechecking (I can tell because I use a subclass of TypeReference), but somehow they end up in the middle of the parser-created global model.

I've been trying to figure this out for most of today; I think I'll give up for now. I really want to make all model classes immutable, as we discussed earlier, to avoid this sort of hard-to-debug problem in the future.

Olivier

[objectiser]

Forgot to mention before - could you raise a jira related to the change of finding an in-model role when doing the projection.

Also, for this issue, if you have a test that demonstrates the problem, can you package it up and attach to another jira.

It would be good to create jira for issues like these, as it makes it easier to keep track of issues that are fixed between releases.

Regards

Gary

[perneto]

Gary Brown wrote:

Forgot to mention before - could you raise a jira related to the change of finding an in-model role when doing the projection.

Sure, I'll do that.

Also, for this issue, if you have a test that demonstrates the problem, can you package it up and attach to another jira.

It would be good to create jira for issues like these, as it makes it easier to keep track of issues that are fixed between releases.

I don't think I can easily reproduce the problem out of my project - like I said, I could only reproduce it by running two specific tests together. There is something wrong with Scribble though, as the change of Roles I gave the code snippets for should not make any difference.

Anyway, I'm getting a similar problem now with the packaged compiler plugin, where role.getParent() is null. When I manage to sort this out I'll add a jira ticket.

Cheers,

Olivier