Closed sezaru closed 6 years ago
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!
Here is what to expect next, and if anyone wants to comment, keep these things in mind.
That is what MFC or Qt does. It's nice that every event has its own function handler. But I have no idea how these are going to wire back up with the main program. It might end up just hiding that main update function, and that's not going to improve thing much. 🍨
Do you mean how we would add the update functions to main
like that:
main =
Html.program
{ init = init
, view = view
, update = update
, subscriptions = subscriptions
}
Right?
Well, since all the updates functions have the same definition update : Msg -> Model -> ( Model, Cmd Msg )
only differing in the pattern matching of the Msg
type, my guess is that the compiler could convert it to a single function using case of
.
So we still just need to add one update function to the main like we do now.
Would that be possible?
I think this is what Elixir does behind the scenes, the Erlang VM try to match all the functions with the same name, arity and type from top to bottom and execute the matched one.
The nice thing is that this is totally transparent to the developer.
Also, the idea of function signature pattern matching goes way beyond the update function, i just used it as an example because it was a obvious one to me.
But if we can have pattern matching for lists contents, strings, etc. We can reduce a lot of complicated conditional code in functions like:
doSomething : List String -> String
doSomething = []
-- Empty list
...
doSomething = [a]
-- List with one string a, get a
...
doSomething = a::_
-- List with more than one string, get a
...
Multiple definitions with implicit pattern matching, while theoretically possible, is not something I think Evan would like to add to Elm. His style-guide for Haskell code (which does support that particular feature) outlines some of the reasons.
More importantly, the issues are for bugs, not feature proposals.
Using the Elm Architecture, normally the component's update function will grow as the same pace as new messages are added to it.
That means that we normally see code like this:
My proposal is to be able to do pattern matching directly in the function definition, so we can break the update function in smaller, non-conditional and easier to test functions:
Note that I'm fairly new to the language and I'm not sure if this syntax would be possible/valid, but coming from Elixir, the function definition pattern match was the first thing I missed in Elm.