I'm definately with Wouter on this one. Using tasks to do something that isn't a side-effect sounds much more like a code smell than using plain old function calls and function return values to compose your logic (when that is possible, which I would imagine would be true most of the time, if not all the time when there aren't any side-effects involved).
I've seen this argument a while back related to people using a super nested TEA and getting tiered of boiler-plate (function calls and function return values), and using Tasks as a get out of jail card (for "child-parent", "child-sibling" etc communication). Resorting to tasks might be Easy (at hand), but it's certainly not Simple (especially considering the asynchronous scheduler). I respectfully disagree. Depending on the application, this either may not > be possible or would be a terrible code smell. I honestly think the above > suggestion would be worse than chaining another Cmd msg. Sending another > Cmd msg is clean and follows the Elm architecture. > It would be interesting to see some concrete examples of were it would not be possible or a code smell to use functions (rather than tasks) for non-side effecty things. Maybe I can be convinced. Another case that wouldn't work out so well for is the init function. The > init function returns a (model, Cmd msg). I think it'd be much cleaner for > the init function to call sendMsg (or equivalent) instead of the init > function calling either my update function or the function that would be > called for that msg. > Why do you think 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.
