Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge MutableModels with Models #25

Open
elliottwilliams opened this issue Jan 19, 2017 · 0 comments
Open

Merge MutableModels with Models #25

elliottwilliams opened this issue Jan 19, 2017 · 0 comments
Milestone

Comments

@elliottwilliams
Copy link
Member

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
@elliottwilliams elliottwilliams added this to the v1.1 milestone Jan 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant