Event Driven Programming Pdf

[Dominik Ransom]

Becausethe event loop of retrieving/dispatching of events are common amongst applications, many programming frameworks take care of their implementation and expect the user to provide only the code for the event handlers.

RPG, an early programming language from IBM, whose 1960s design concept was similar to event-driven programming discussed above, provided a built-in main I/O loop (known as the "program cycle") where the calculations responded in accordance to 'indicators' (flags) that were set earlier in the cycle.

The actual logic is contained in event-handler routines. These routines handle the events to which the main program will respond. For example, a single left-button mouse-click on a command button in a GUI program may trigger a routine that will open another window, save data to a database or exit the application. Many IDEs provide the programmer with GUI event templates, allowing the programmer to focus on writing the event code.

While keeping track of history is normally trivial in a sequential program. Because event handlers execute in response to external events, correctly structuring the handlers to work when called in any order can require special attention and planning in an event-driven program.

In addition to writing the event handlers, event handlers also need to be bound to events so that the correct function is called when the event takes place. For UI events, many IDEs combine the two steps: double-click on a button, and the editor creates an (empty) event handler associated with the user clicking the button and opens a text window so you can edit the event handler.

Most existing GUI architectures use event-driven programming.[2] Windows has an event loop. The Java AWT framework processes all UI changes on a single thread, called the Event dispatching thread. Similarly, all UI updates in the Java framework JavaFX occur on the JavaFX Application Thread.[3]

Event driven programming revolves around so-called events, which are abstract things that programs "fire" when something happens. Other places in your code "listen" for the events and respond with what they need to do when that event happens. For instance, an event could be "user pressed this button" or "the printer is done printing your document".

Reactive programming deals with data. Ultimately this is a special case of event-driven programming. The event: data changed. The event handler: change some more data (if applicable). This concept is usually cleared up when you think of a spreadsheet. If you set cell1 = cell2 + cell3 this implicitly sets two event handlers on the data changed events of cell2 and cell3 to update cell1's data. cell1's data has no such event handler, because no cells depend on it's value.

Event driven programming: structures your program in order to deal with ("handle") something else that happens in your program (an "event"). In other words, it structures your code logically like this

Nothing really special here, except it's another way to think of the order in which your code is executed. For instance, promises are useful when you make a call to a remote machine. With promises, you can say "call me back when you return from this remote call!". Whichever library you use then promises to call you back when it gets something back from the remote machine. Often, this is useful because it lets you do something else in the meantime without waiting for the call to return.

Punch line: there are a lot of different styles of code, but they don't play too big a role in the pattern of event driven and reactive programming. To my knowledge, you can do event driven and/or reactive programming in most languages.

Both code snippets do the same thing, but there is a big difference in thinking: with promises you are thinking about handling a single action with async steps in a clear way - the thinking is imperative, you are doing things step by step. With FRP, you a saying "a stream of usernames is created from the stream of userIds by applying these two transformation steps". When you have a stream of usernames, without caring where they came from, and say "whenever there is a new username, display it to the user".

The FRP coding style will guide you to model your problem as a stream of values (i.e. values that change over time) and the relationships between these values. If you already know Promises, the initial learning curve will be a bit easier, but the main benefit is gained only when you start thinking and modeling the problem differently - it is possible (if not very useful) to do imperative programming with FRP libraries.

In reactive programming, you declare a reaction to a change. You don't have to forsee this reaction needed to that change upfront, you may add - declare - this reaction anytime later. Therefore, it might be considered a "pull" or "watch" strategy.

Example Calculator App: the calculator display is bound to all buttons, and reacts with any change (clicks on the buttons) with its own change on the display. Buttons don't have awareness that their clicks can be utilized by any other parts.

In event-driven programming, you trigger an event in a certain situation in the imperative-written code. You need to be explicit upfront here, because the event needs to be triggered first in order to be received later - because basically you push the event in the "change happening" part of code. So it is a "push" strategy.

Therefore, in event-driven programming, you push an event in a certain situation that maybe would be received by some other parts of code. Situation is important here, data does not matter.

Example: someone has visited the contact page -> trigger an event (which might not be received at all in the end by any listener, which is typical case for many modules and libraries).

Example Calculator App: the calculator display is just a listener, and the buttons trigger events. Buttons need to know that they exist in a certain context (but - thanks to the event-listener pattern - don't have to know what exactly is that context), and therefore they are required to trigger an event.

You may say, then, that reaction is bound to a in reactive approach, while in imperative event-driven approach you push an event that can be later received by a listener - and since this type of approach is not related by any means to data, you may change this: a += value to anything else later, even removing a completely.

So as you see, reactive programming is data-oriented (change in data reacts with triggering other code), while event-driven programming is process-oriented (it doesn't matter if and what data change, if any - you just trigger an event that would be received by some other parts of code). In the latter case, you need to know that this "informing" the other parts of code is required, and you have to then foresee that the event should be triggered. In the former case, you don't have to do that, you can do it any time, or not at all - no triggering events required - but the trick here is that there must be "something" that you can hook up to with your reaction declaration, kind of watchers which allow you to react to the watched changes.

Reactive programming is all about streams, it could be streams of events, or anything else. It is on emitting/announcing these streams or subscribing/watching these streams or stream transformations that lead to some events. So both programming paradigms are related.

Reactive programming is a programming paradigm that is applied when one wants to achieve a functionality akin to data binding in libraries like KnockoutJS. Also an example would be Excel formulas: all cells are like variables in memory. There are those that simply hold some data and those which are computed from that data. If the former changes, so does the latter. Pay attention that the paradigm is about lower-level implementation; when someone is talking about reactive programming they are referring to data, its changes and what happens when it mutates.

On the other hand, event-driven programming is about system architecture. According to that paradigm events and event handlers are the basis of a system and everything is built upon and around them. Common examples would be UI and web server multiplexing. Do you feel how all this is different? The paradigm is applied on the level of a whole system or a subsystem.

In practice the paradigms serve different purposes and at different levels. You can have event-driven design with some bits of reactive code. You can have distributed system that uses reactive design patterns. However, events are ultimately higher-level concept. Reactive is about data and its re-evaluation, an approach for implementation or its detail, and events are something that naturally come up from a case and drive your design.

I want to state very clearly that this does not intend to revive the discussion about functional/procedural programming versus object-oriented programming. There is plenty said about that, on WPSE and all over the net.

But a while ago I'm reading over some of the discussions about the programming foundations of Wordpress and I read something - I have to rephrase because unfortunately I didn't bookmarked it at the time - roughly like this:

From what I understand event-driven programming in this context is pretty much synonym to signal or dataflow programming. Furthermore - most likely oversimplifying it a lot - maybe the main apparent characteristic is the use of hooks - actions and filters - as linchpin for the method.

So far so good. Seems easy enough, but I'm not coming from a computer science background, so I'm pretty sure there is more to be said. I'm really interested in some input, like: What is it really about or is the above said pretty much it? Is it an extra paradigm? How does it relate to the other ones? Is it a core principle or just an addition?

3a8082e126