Naming of "Cmd"

The Elmish framework use the name “Cmd” to mean something that, when started, may asynchronously generate messages.

There are issues with using “command” in the context of Xamarin.Forms programming (also WPF) because ICommand, Command etc. are used in Xaml/WPF/XF docs. I’ve also never really liked the name for these reasons, though I’m suspect Fable-Elmish people are ok with it.

I do wonder if we should find another name for this in the context of EXF, or simply not really have a name for it at all. In EXF samples people tend to make cmd values from

• Async<Msg> (Cmd.ofAsyncMsg)
• Async<Msg option> (Cmd.ofAsyncMsgOption)
• AsyncSeq<Msg> (used to be used but wanted to remove dependency on FSharp.Control.AsyncSeq)
• (I guess people could also use IObservable<Msg> and it would be basically equivalent)

Then also Cmd.batch to merge two commands together.

It’s hard to rename though since likely all other good names are taken (action, process, async). Any thoughts?

[dsyme]

I’m not necessarily looking for a change 😃 It’s just that I’m always dissatisfied with having to explain “Cmd”. Everything else in the model is so 100% intuitive - as soon as people read the code they get it.

Schedule is actually good, in the sense that the code Schedule.nothing, Schedule.msgAfter, Schedule.asyncMsg etc. is very clear. People will know exactly what that is doing (and know it is doing nothing more than it says). Perhaps that’s partly because schedule can be both noun and verb in english and either interpretation here makes sense.

Again not saying we should change, just mentioning it as a problem (for Elmish in all its forms)

[Zaid-Ajaj]

The name comes from the original Elm architecture, anyone who uses or has used Elm is already familiar with the concept of a “Cmd”, I don’t think it is a problem with WPF /XF because if you use Elmish, you don’t explicitly use IConmand anymore