So, the stronger wording seems better, so that 'needs fixing' is resolved. As for having two libraries vs the one, I'm on the fence, so I won't object. I somewhat like that there's less temptation to roll these functions into the public api.
As for the DebuggingSessionMediator, it seems to me that the SessionMediator should depend on (via a constructor parameter) some object that is capable of looking up the coordinates. A debug implementation of this object would lookup the coordinates, the normal implementation would throw when the lookup is attempted.
OTOH, SessionMediator already has a pretty bloated constructor... but I'd rather have one bloated constructor on SessionMediator than a bloated constructor on both SessionMediator and DebuggingSessionMediator.
So, the stronger wording seems better, so that 'needs fixing' is resolved. As for having two libraries vs the one, I'm on the fence, so I won't object. I somewhat like that there's less temptation to roll these functions into the public api.
As for the DebuggingSessio nMediator, it seems to me that the SessionMediator should depend on (via a constructor parameter) some object that is capable of looking up the coordinates. A debug implementation of this object would lookup the coordinates, the normal implementation would throw when the lookup is attempted. nMediator.
OTOH, SessionMediator already has a pretty bloated constructor... but I'd rather have one bloated constructor on SessionMediator than a bloated constructor on both SessionMediator and DebuggingSessio