3 ms·

My first contact with event driven programming was coding for the original Windows C API, back in 1990. Nowadays we call that API Win32, but then it may have be

My first contact with event driven programming was coding for the original Windows C API, back in 1990. Nowadays we call that API Win32, but then it may have been win 16. Switching from the traditional imperative style to callbacks was a big deal: don't call us, we'll call you! [1] and [2] show the difference in coding style. Later in the 90s C++ wrappers like MFC and XVT simplified things, but the paradigm was still an inversion of control. And that's what event driven means to me. [1] http://www.paulgriffiths.net/program/c/srcs/hellosrc.html http://www.paulgriffiths.net/program/c/srcs/hellosrc.html [2] http://www.paulgriffiths.net/program/c/srcs/winhellosrc.html http://www.paulgriffiths.net/program/c/srcs/winhellosrc.html

barrkel 10y ago
Unless you do async operations, UI framework programming with callbacks doesn't really approach the full horror that can exist in some styles of event-based programming. UI events are typically of two kinds: user performed an action and you need to update the model / execute a command, or the view is asking for information and you need to translate it from the model. Both are fairly encapsulated; the larger operation doesn't extend beyond the scope of the callback, and if it does (e.g. showing a modal dialog), you can use a nested event loop to take care of event dispatching while showing the modal. The events in a UI are also naturally scoped to the screen being shown. When the screen goes away, you can rely on those events not being dispatched any more. Events get to party on a shared state (the model, perhaps attributes of the view) but scoped within the view being displayed. It's all pretty flat. You also don't need to worry much about concurrency, unless doing async.