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 [email protected]. For more options, visit https://groups.google.com/d/optout.
