Code review comment for lp:~alan-griffiths/mir/surface-states-simplification

> Secondly, I disagree with the approach. There are no strong "dependencies" here.

As mentioned in an older comment [1], they are effectively dependencies because of how Mir uses the class. That is, in all cases in production code we need to set both the id and the sink for our features to work properly.

> If Mir was to support such a thing in future then it would be handy to be able to re-assign
> a surface to a different session

The key words are "if ... in the future ...". If we need this in the future, we are free to change the code to suit our needs. Right now the values are meant to be set only once at creation time, and accepting them in the constructor enforces this restriction (and, as mentioned above, also enforces that we always get a fully working object).

[1] https://code.launchpad.net/~vanvugt/mir/surface-states/+merge/158289/comments/348068