It's been in my mind for a couple months that there's no good reason for keeping the distinction between MutableModels and Models around, and so at some point I'd like to merge the two types of models. Originally, I kept them separate for two reasons:
- Parts of the application that don't need subscriptions to model objects (i.e. don't need live updates) could just get
Models rather than MutableModels.
- A conceptual design of
Models being the "messages" from WAMP services, and MutableModels being the representations and receivers of these messages to the UI.
However, in practice:
MutableModels are "dead" at first (they won't subscribe and begin updating themselves until their producer is started). So using them doesn't incur a network cost per se.
- The real "message" format is JSON. Anything that implements
Decodable can receive messages from WAMP services.
- There has been no point so far in the UI code where I need a model object but explicitly do not want live updates.
- Caching of
last_event and subscription deferring has reduced the cost of recreating MutableModels. I'm thinking about creating a pool of reusable MutableModels, too, which would further this.
So I'd like to experiment at some point merging these two together. I would make MutableModels decodable, then rename the classes. The test code would have to be updated, which would be a pain, but I think refactoring the app itself would be easy.
This would also be a good time for other MutableModel work / experiments:
- removing its delegate (it's no longer needed due to the way
producer works)
- using init? and result types instead of throwing errors on inconsistent state
- change properties to
AnyProperty and propagate changes through a signal rather than apply
It's been in my mind for a couple months that there's no good reason for keeping the distinction between
MutableModelsandModelsaround, and so at some point I'd like to merge the two types of models. Originally, I kept them separate for two reasons:Modelsrather thanMutableModels.Modelsbeing the "messages" from WAMP services, andMutableModelsbeing the representations and receivers of these messages to the UI.However, in practice:
MutableModelsare "dead" at first (they won't subscribe and begin updating themselves until theirproduceris started). So using them doesn't incur a network cost per se.Decodablecan receive messages from WAMP services.last_eventand subscription deferring has reduced the cost of recreatingMutableModels. I'm thinking about creating a pool of reusableMutableModels, too, which would further this.So I'd like to experiment at some point merging these two together. I would make
MutableModelsdecodable, then rename the classes. The test code would have to be updated, which would be a pain, but I think refactoring the app itself would be easy.This would also be a good time for other
MutableModelwork / experiments:producerworks)AnyPropertyand propagate changes through a signal rather thanapply