Thanks for the response. Adding a new Plugin is actually quite straight forward, it just requires some more boiler plate code, which is some what ugly, but as you say, also explicit.
But what i dont like about my approach in particular is that i *know* that when there is an update to, say the SimplePlugin, it will *always* be a SimplePluginMessage. In a language like Java i would simply cast a generic PluginMessage into a SimplePluginMessage and then pass that to the update method of a SimplePlugin instance. In Elm of course i cant do that and have to destructure the Message as well as the Model in order to pass the msg and model records to the correct function, and disregard them if they don't fit together. I think this problem could be solved by following Richard Feldman's advice of not allowing impossible state. It should not be allowed to call the update function of the PluginDispatcher module with a PluginMessage that is unrelated to the actual Plugin. But there lies the problem: how do i correctly model that? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
