Be clear that `thing_settings` are not available during `__init__`

[rwb27]

A Thing object should have a ThingSettings object available at self.thing_settings to persist data. Currently, this is supplied when the Thing is added to the server, i.e. after __init__ has run. This has the potential to be quite confusing, I think.

The reason this is done is that we don't know where the settings file should be until there's a server involved - because the settings location is a property of the server. It might be possible to change this, for example by making sure that Things are always instantiated after the server - adding a mandatory server argument or perhaps using a context variable.

Resolution: Keep the current behaviour, but make it clear that settings will only have their values available after the Thing is connected to a ThingServer.

[julianstirling]

I don't think this is really an issue. I think that as long as it is well documented that a Thing needs to be connected to a server for the server to load settings from disk is fine. Lots of things don't work if it isn't connected to a server, and it gives a sensible error message.

The main place this is an issue is with testing, when not connected to the server. But this is easy because when testing you don't want to load from disk, you want to set custom settings. So in mocked classes for testing I just overwrite the settings dictionary with a plain dictionary with the settings for testing.

[rwb27]

That makes sense, I think it's reasonable to leave it as-is and just make sure we document that settings will only have their correct value once connected to a server (i.e. after __init__ but before __enter__). I'll update the description accordingly.

[rwb27]

As to the testing use case, that makes lots of sense. My only comment is that we probably want to make sure that behaviour is opt-in.

If I instantiate a Thing and then set up for testing, it uses defaults and doesn't persist to disk (or does so to a temp location), and that's ideal.

If I instantiate a Thing and then access settings in __init__ (or elsewhere), I think it would be helpful to have an error - otherwise we might set things up based on the defaults, then overwrite the settings when they are loaded. That might put the Thing into an inconsistent state, or at least be quite confusing.

[julianstirling]

As of #110, the settings are available at __init__ but are only updated to their persistent value on disk when added to server. This functionality is tested with a unit test.