Observable functional properties

[rwb27]

Is your feature request related to a problem? Please describe.
Currently data properties are observable but functional properties are not. This is annoying when it would be useful to get websocket updates about functional properties. See OFM#883.

Describe the solution you'd like
I think there are two ways to address this, both of which have their place:

• Allow functional properties to be marked as observable, but rely on the Thing to manually notify their changes. LabThings would be responsible for handling pub/sub logic and generating the Thing Desciption, but would not actually generate notifications: that would need to be instigated manually by the Thing. This would probably be more feasible if data properties could have side effects (Property side-effects with @lt.on_set #331).
• Introduce computed properties. Most reactive frameworks provide some sort of computed property. This would allow a new Property to be defined that's a function of other Properties. LabThings would then be able to keep track of which properties might change a computed property, and recompute it when they change.

I think the first option has its place, and is in fact already possible with existing internals. However, I would like to be quite careful about how it's exposed, because there's potential for a lot of confusion if the feature is used incorrectly. I also think LabThings could be much more helpful in most cases.

I think computed properties might not be that bad to implement, and it's worth testing out the idea. I think the tricky bit is how to avoid strange behaviour (e.g. reading things that are not observable, or having side-effects). Most reactive frameworks I've seen will just go wrong if you do naughty things in computed properties, so we probably needn't be too restrictive - but I think the whole thing does work much more elegantly if LabThings can keep track of which attributes are being accessed.

A sensible place to start with computed properties would be to allow a computed property to depend on data properties and computed properties of the same Thing. This could then be extended to allow Thing Slots to be used as well. I think the easiest implementation would be a thin wrapper around self so we can track attribute access.

[rwb27]

Currently, it is possible to set the observable property on a FunctionalProperty:

import labthings_fastapi as lt

class MyThing(lt.Thing):
    quantity: int = lt.property(default=0)

    @lt.property
    def doubled(self) -> int:
        """Twice quantity."""
        return self.quantity * 2

    doubled.observable = True

Any code that changes quantity would then need to manually notify subscribers that doubled has changed:

from labthings_fastapi.message_broker import Message

self._thing_server_interface.publish(
    Message(self.name, "doubled", "property", self.doubled)
)

Message isn't yet in the public API, largely because I think it may want to change in the future (e.g. having different types for different kinds of message).

I think the minimal change needed to advertise observable functional properties would be:

1. Emit an easily-silenced warning when a functional property is marked as observable
2. Expose a shorthand for the notification code above. This would isolate the calling code from any future changes in Message so would be easier to add to the public API. For example, self.properties["doubled"].publish(). I think it's reasonable to assume that the value we're publishing should always be the value returned from getting the property. Anything else probably wants to be an Event instead.