Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a Event and signal driven programming techniques
Semelhante a Event and signal driven programming techniques (20)
Mais de Elizabeth Smith
Mais de Elizabeth Smith (20)
Último
Último (20)
Event and signal driven programming techniques
- 1. The wheel already exists… EVENT AND SIGNAL DRIVEN PROGRAMMING TECHNIQUES
- 2. CS Lesson Lecture Rant Tutorial Talk FEEDBACK IS PRECIOUS
- 3. Patterns and Concepts – oh my IN THE BEGINNING – CS 201
- 4. STRUCTURED PROGRAMMING simple, hierarchical program flow structures sequence selection repetition procedural adds sub-routines or functions object oriented modularizes components of code
- 5. EVENT DRIVEN PROGRAMMING Wait for Events Handlers Accept are Called Event Dispatch Event
- 6. TRANSITIONING TO EVENTS code flow is controlled by the user, not the program software can sit “idle” until an event occurs allows software to react why?
- 7. PUBLISH/SUBSCRIBE type of event programming this is NOT observer publisher and subscriber are decoupled subscribers express interest in a state change/event/message/signal each subscriber receives a copy
- 8. SUBJECT/OBSERVER this is a subset of publish/subscribe NOT the other way around in this case, the subject maintains the observers and notifies them of state change/event/message/signal more tightly coupled then publish/subscribe
- 9. EVENT/HANDLER events are spawned by the system events are dispatched to handlers which are attached to them handler can go by many names – callback, closure, function events might have priority, might interrupt depending on the dispatch method used
- 10. SIGNAL/SLOT signal – something you know is going to happen that is attached to a class slot – method in a class that can be connected to a signal connect a signal to a slot (wire it up) emit the signal requires oo
- 11. ASYNCRONOUS VS. SYNCHRONOUS event-driven !== asynchronous structured !== synchronous concurrency through Async I/O (epoll, IOCP, kqueue, et al) threads forking (multi-process)
- 12. (MAIN) EVENT LOOP poll event provider blocks until event arrives calls the event handler (dispatches) main is added if it is the highest level of control in a program
- 13. DISPATCHER gets event determines which handlers get called eitherattached determined by type stored in some manner calls the handlers
- 14. MESSAGE QUEUE Buffers the input stream of events FIFO usually, unless priority or other features are present in the queue while(events_pending)
- 15. EVENT DRIVEN STATE MACHINE A number of behavioral nodes waiting for a trigger to execute the transition The trigger in this case is an event
- 16. REACTOR Service Request Demultiplexer and Dispatcher Synchronous Request Handlers
- 17. INTERRUPTS asynchronous signal/event indicating need for change in execution or need for attention “The ship is going to explode” A signal is a software interrupt delivered to a process
- 18. The Wheels keep on Turning WE’VE BEEN DOING THIS ALL ALONG
- 19. KERNEL SIGNALS “Get off my Lawn!”
- 20. USING IT WITH PHP PCNTL very simplistic most signals (other then SIGUSR1 and SIGUSR2) have predefined meanings
- 21. XLIB SIGNALS 1985 called and they want their shoes.
- 22. XLIB AND XNEXTEVENT blocks until event appears in the queue application process it only handles window system events calling xlib functions from a signal handler “POOF”
- 23. GOBJECT (FORMERLY GTK+) Gimp wanted a nice toolkit and had a gnome
- 24. GOBJECT IN PHP PHP-GTK PHP-GTK (next) Extend gobject class define your signals attach to your signals emit your signals
- 25. FEATURES Register Signal Connect Signal to Closure Emit Signal User Data Accumulators Details
- 26. GOBJECT EVENT LOOP Manages all sources of events Event type can be added Gmaincontext for each thread to manage sources Priorities for event sources and idle functions
- 27. QT For those who like a little ++ with their C
- 28. QT – “EVENTS” AND “SIGNAL/SLOT” event – virtual function in a class you reimplement to handle the event signal – wired to a callback (slot) by a metaobject class, no loop necessarily required
- 29. WIN API Pump that message baby
- 31. .NET The windows api, memory managed and less sucky
- 33. LIBEVENT (NODE.JS, TWISTED, EVENTMACHINE…) It’s all in the family!
- 35. Deep Thoughts on Good Code BEST PRACTICES
- 36. THE LEGACY OF HTTP
- 37. WHY EVENTS OR SIGNALS?
- 38. IMPORTANCE OF CLOSURES AND TRAITS
- 39. NAME IT PROPERLY Publish / Subscribe Dispatcher Decoupled (Main) Event Loop Subject / Observer State Machine stateless Message Pump Event / Handler Reactor event loop Signal / Slot Tightly coupled objects Traits
- 40. STANDARD INTERFACES Observer? Use SplSubject and SplObserver Pub/Sub? Event/Handler? Signal/Slot?
- 41. BORROW FROM OTHER LANGUAGES Any C based language translates REALLY well to PHP If you can’t depend on an extension, but want to “drop it in” – do the same API in a different namespace and class_alias as appropriate Upgrading from stone wheels to vulcanized rubber is great, but don’t reinvent
- 42. Event Driven Code in Action IN THE WILD
- 43. ZF2 EventManager (aggregator, trigger events ) Listener (callback) Event (action modeled as object)
- 44. SYMFONY COMPONENTS – EVENT DISPATCHER Register of listeners Event object notify, notifyUntil, filter
- 45. ZETA COMPONENTS Component – SignalSlot signal as event, slot as callable priorities static connection (hook)
- 46. ALMOST BUT NOT QUITE Lithium Prado Wordpress Symfony 1
- 47. THE FUTURE? Best new hope for clean, easy eventing implementations? Traits Some good wrappers around existing C libraries (libevent, dbus, glib/gobject, qt, winapi, .NET) Pulling in good ideas from other languages, PHP evolves
- 48. RESOURCES http://components.symfony-project.org/event- dispatcher/ http://incubator.apache.org/zetacomponents/doc umentation/trunk/SignalSlot/tutorial.html http://weierophinney.net/matthew/archives/266- Using-the-ZF2-EventManager.html http://c2.com/cgi/wiki?EventDrivenProgramming http://eventdrivenpgm.sourceforge.net/ http://www.gtk.org/ http://qt.nokia.com
- 49. BRING IT ON Good Libraries Blog posts Articles Extensions
- 50. CONTACT ME http://emsmith.net http://joind.in/3756 auroraeosrose@gmail.com IRC – freenode – auroraeosrose #php-gtk #coapp and others
Notas do Editor
- Although event driven programming has been around for many years, it's relatively new as an "engine" in the PHP community. Learn the concepts of event programming, and by extension signal driven programming, from the toolkits that have made it standard - Qt, winapi, .NET, GTK+ - and learn how to apply them to your next PHP project. Also learn about extensions and libraries to use for speed4:00 startShort “whoami”Who am I, and why should you listen to me?Windows buildsCairo, PHP-Gtk, Win\\GuiUsing PHP since php 4 betaHow I got involved in PHP community and why you should tooHow I got interested in event programming – my foray into desktop, winapi and gtk coding
- These are my goals for the talk – I’m going to give a CS lesson on event driven programmingI’m going to give a lecture on the original creators and users of event driven programmingI’m going to rant, probably quite a bit, on event driven programming in PHP and it’s current directionThen I’ll give some tips and tricks for writing GREAT event driven code in PHPAnd finally wrap it up with some current PHP programs using events or planning to in next release and the direction I’d like to take events in PHPSome notes: this is marked as “advanced” for a reason. You will see some C code, some JAVA, get a 15 minute computer science lecture, and see very little PHP. If you thought this was code heavy or an in depth lecture on event driven programming you’re out of luck
- In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads.Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.Start 4:02 or so – concepts of event driven/event based programming
- In the beginning there was structural programming"Sequence" refers to an ordered execution of statements.In "selection" one of a number of statements is executed depending on the state of the program. This is usually expressed with keywords such as if..then..else..endif, switch, or case.In "repetition" a statement is executed until the program reaches a certain state, or operations have been applied to every element of a collection. This is usually expressed with keywords such as while, repeat, for or do..until. Often it is recommended that each loop should only have one entry point (and in the original structural programming, also only one exit point, and a few languages enforce this).The last can also be termed “iteration”
- Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.
- What if instead of tightly controlling the run of a program, the software just sits idle until the user does something? Inother words, the flow of the program is controlled by user-generated eventsThis is probably the most important conceptual part of even-driven programming: the user is in control of your code.This has vast-implications on the type of code you write. For one, you can't expect the user to follow a predefinedexecution path (unless you go to great pains to enforce one). Instead, the system must be much more open-ended.This means more robust error-handling--you can NEVER assume the user has entered data in a certain order orprocessed one event over another, etcAt first glance, even-driven programming seems more complex than structured programming, and in a sense this istrue. However, an event-driven structure eases complexity by allowing you to program in the context of what the useris doing. If the problem can be thought of in the user's terms, that can make programming it a much more satisfying,and less-error prone process.The biggest answer to “why events” is twofold – first for a gui application (which is where event programming really took off) it makes sense for the program to react to actions taken by a user Let’s contrast this to a basic web application with a simple request -> response lifecycleThe second reason for “why events” is related to extendability – when events are done properly ANYTHING can be attached to them – this makes features such as hooks and plugins and apis far easier to implement in a system, instead of conforming to some functional api or extending a class, etc, you simply attach to the events you want to listen to (the strength of observer pattern is here)
- Pub/sub is a messaging pattern where senders(publishers) of messages do not program the messages to be sent directly to specific receivers(subscribers). Published messages are characterized into classes,without knowledge of what, if any,subscribers there may be. subscribers express interest in one or more classes,and only receivers messages that are of interest ,without knowledge of what, if any, publishers there are.Pdated automatically. the decoupling of publisher from subscribera simple mailing list is an excellent example of publish subscribe.Issues to watch for:When you publish, are you publishing to everyone that is supposed to get the message? This is a system start/failover issue. Different nodes come up at different times, which means they will register at different times. Data can be lost. Publish is a push technology, which means a chatty sender can overload the system. This may also cause memory and network problems (drops)Message order is often important. If the publisher maintains order, then how does it deal with a situation where one or more consumers have drops? The entire cohort will be held back waiting for retransmission.
- in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.this is best known way of implementing an eventing systemThe essence of the Observer Pattern is to "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and up
- dispatchers tend to be one per process, but can also be one per threadso event happens dispatcher takes event and passes to handlers that have bee nattached to the event type
- Signals represent callbacks with multiple targets, and are also called publishers or events in similar systems. Signals are connected to some set of slots, which are callback receivers (also called event targets or subscribers), which are called when the signal is "emitted.“Signals and slots are managed, in that signals and slots (or, more properly, objects that occur as part of the slots) track all connections and are capable of automatically disconnecting signal/slot connections when either is destroyed. This enables the user to make signal/slot connections without expendOlder toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws: Firstly, they are not type-safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call.ing a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved.
- And here is where people make their mistake – not all event driven programming is synchronous, not all procedural/structural is asyncThe ability to be asynchronous is tied to use a parallel/concurrent programming method and has absolutely nada to do with your choice to do structured or event-driven code
- This is fairly self explanatory. Event driven programming (and event/handler, signal/slot by extension) use some kind of a main loop in their program to get the events in and the handlers/slots pushed out
- Some applications (for example, applications that control hardware) may treat the event streamas effectively infinite. But for most event-handling applications the event stream is finite, with anend indicated by some special event — an end-of-file marker, or a press of the ESCAPE key, or aleft-click on a CLOSE button in a GUI. In those applications, the dispatcher logic must include aquit capability to break out of the event loop when the end-of-event-stream event is detected.In some situations, the dispatcher may determine that it has no appropriate handler for the event.In those situations, it can either discard the event or raise (throw) an exception. GUI applicationsare typically interested in certain kinds of events (e.g. mouse button clicks) but uninterested inothers (e.g. mouse movement events). So in GUI applications, events without handlers aretypically discarded. For most other kinds of applications, an unrecognized event constitutes anerror in the input stream and the appropriate action is to raise an exception.
- In some cases, the dispatcher and its handlers may not be able to handle events as quickly as theyarrive. In such cases, the solution is to buffer the input stream of events by introducing an eventqueue into the events stream, between the events generator and the dispatcher. Events are addedto the end of the queue as fast as they arrive, and the dispatcher takes them off the front of thequeue as fast as it is able.This is usually done in gui applications – the other option is to block until processing of the previous message is complete or to allow recursive event spawning (glib does this for example)This is the kind of behaviour that is often seen in event driven GUI frameworks when one wants to do continuous animation. I'm going to guess that eye::playSequence is called from a button click or maybe from some point during the application startup code? In any case, here is what's going on.Qt uses the main application thread to drive an event loop. The event loop is something like this:while(app_running){ if(EventPending) ProcessNextEvent();
- A state describes a behavioral node of the system in which it is waiting for a trigger to execute a transition. Typically a state is introduced when the system does not react the same way to the same trigger. The gsignals code actually implements this in it’s emitter – as each signal is emited the gsignal code keeps track of the state of the system in a “run state”This is how it deals with recursion inside signal emission and other thorny details of a good eventing system
- This is twisted, libevent/libev, node, eventmachineThis is select, epoll/poll, IOCP on windows (well for a GOOD library, bad libev), and kqueueTo combine multiple signals for transmission over a single line or media.To separate two or more channels previously multiplexed. Demultiplexing is the reverse of multiplexing. The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs.The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.The Reactor Pattern is a design pattern for synchronous demultiplexing and dispatching of concurrently arriving events. It receives incoming messages/requests/connections from multiple concurrent clients and processes these messages sequentially using event handlers.The purpose of the Reactor design pattern is to avoid the common problem of creating a thread for each incoming message/request/connection. It receives events from a set of handles and distributes them sequentially to the corresponding event handlers. Thus, the application using the Reactor need only use one thread to handle concurrently arriving events.Basically the Reactor pattern allows an application to handle concurrent events while retaining the simplicity of single-threading.
- interrupt is an asynchronous signal indicating the need for attention or a synchronous event in software indicating the need for a change in execution.
- 4:10 – our world tour of “how other people do it”Do my rant on “reinventing the wheel” and how I hate that termOften you learn more or do more by writing your own wheel. What I should NEVER see is someone who doesn’t look at other implementations – other languages, other libraries, tried and true ways of getting stuff done.
- The original signalsPosix extension – used primarily to allow communication between Signals offer another way to transition between Kernel and User Space. While system call are synchronous calls originating from User Space, signals are asynchronous messages coming from Kernel space. Signals are always delivered by the Kernel but they can be initiated by:These are quick messages that must be handled and are still considered “event driven” mechanism – the signals are sent out and the code must do something with thOne of the few things in Unix that do not conform to the file interface are asynchronous events (signals). Signals are received in signal handlers, small, limited pieces of code that run while the rest of the task is suspended; if a signal is received and handled while the task is blocking in select() then select will return early with EINTR; if a signal is received while the task is CPU bound then the task will be suspended between instructions until the signal handler returns.em – handle them, before anything can continue along
- SO the process control extension gives you access to the signal functionality of the linux/unix kernels at the PHP level. However unless you whine enough that I push through my patches to have pcntl on windows (-fork, +spawn) then you’re kind of out of luck if you need something cross platform.This is very simplistic eventing in any case and is really more useful for parallel processing using fork/spawning and managing children/etc
- Xlib signals were the next iterationNote that they don’t always play well with kernel level signalsNote there isn’t a wrapper or anything for this (why would you want one) – most of this has “transitioned” to something higher level using itXlib is an X Window System protocol client library written in the C programming language. It contains functions for interacting with an X server. These functions allow programmers to write programs without knowing the details of the protocol. Few applications use Xlib directly; rather, they employ other libraries that use Xlib functions to provide widget toolkits:
- X applications using Xlib directly are built around the XNextEvent family of functions; XNextEvent blocks until an event appears on the event queue, whereupon the application processes it appropriately. The Xlib event loop only handles window system events; applications which need to be able to wait on other files and devices could construct their own event loop from primitives such as ConnectionNumber, but in practice tend to use multithreading.Very few programs use Xlib directly. In the more common case, GUI toolkits based on Xlib usually support adding events. For example, toolkits based on Xtintrinsics have XtAppAddInput() and XtAppAddTimeout().Please note that it is not safe to call Xlib functions from a signal handler, because the X application may have been interrupted in an arbitrary state, e.g. within XNextEvent. See [1] for a solution for X11R5, X11R6 and Xt.
- Originally part of gtk itself, it was split into glib and gtk – glib holds base functionality including the signal/event handling, basic C abstraction, etc since version 2.0 of gtkThe GLib event loop was originally created for use in GTK+ but is now used in non-GUI applications as well, such as D-Bus. The resource polled is the collection of file descriptors the application is interested in; the polling block will be interrupted if a signal arrives or a timeout expires (e.g. if the application has specified a timeout or idle task). While GLib has built-in support for file descriptor and child termination events, it is possible to add an event source for any event that can be handled in a prepare-check-dispatch model.[2]Application libraries that are built on the GLib event loop include GStreamer and the asynchronous I/O methods of GnomeVFS, but GTK+ remains the most visible client library. Events from the windowing system (in X, read off the X socket) are translated by GDK into GTK+ events and emitted as GLib signals on the application's widget objects.
- The main event loop manages all the available sources of events for GLib and GTK+ applications. These events can come from any number of different types of sources such as file descriptors (plain files, pipes or sockets) and timeouts. New types of event sources can also be added using g_source_attach();you don’t even necessarily need to have a main loop running ;)glib calls handlers closures sometimes and handlers others – and have the concept of passing around data and the concept of “accumulators” which I love
- ach signal is registered in the type system together with the type on which it can be emitted: users of the type are said to connect to the signal on a given type instance when they register a closure to be invoked upon the signal emission. Users can also emit the signal by themselves or stop the emission of the signal from within one of the closures connected to the signal. James (again!!) gives a few non-trivial examples of accumulators: “ For instance, you may have an accumulator that ignores NULL returns from closures, and only accumulates the non-NULL ones. Another accumulator may try to return the list of values returned by the closures. ”If a detail is provided by the user to the emission function, it is used during emission to match against the closures which also provide a detail. If the closures' detail does not match the detail provided by the user, they will not be invoked (even though they are connected to a signal which is being emitted). This completely optional filtering mechanism is mainly used as an optimization for signals which are often emitted for many different reasons: the clients can filter out which events they are interested in before the closure's marshalling code runs. For example, this is used extensively by the notify signal of GObject: whenever a property is modified on a GObject, instead of just emitting the notify signal, GObject associates as a detail to this signal emission the name of the property modified. This allows clients who wish to be notified of changes to only one property to filter most events before receiving them. As a simple rule, users can and should set the detail parameter to zero: this will disable completely this optional filtering.
- The gobject signal and main loop are quite abstracted out anymore – in fact d-bus uses this for their loop. It’s generic enough to attach lots of difference event sources to it.The main event loop manages all the available sources of events for GLib and GTK+ applications. These events can come from any number of different types of sources such as file descriptors (plain files, pipes or sockets) and timeouts. New types of event sources can also be added using g_source_attach(). To allow multiple independent sets of sources to be handled in different threads, each source is associated with a GMainContext. A GMainContext can only be running in a single thread, but sources can be added to it and removed from it from other threads. Each event source is assigned a priority. The default priority, G_PRIORITY_DEFAULT, is 0. Values less than 0 denote higher priorities. Values greater than 0 denote lower priorities. Events from high priority sources are always processed before events from lower priority sources. Idle functions can also be added, and assigned a priority. These will be run whenever no events with a higher priority are ready to be processed.
- Qt uses a code generator called MOC or he meta-object compiler to turn the markup you create for signals/slots into “meta objects” with everything includedSignals and slots are Qt mechanism, in process of compilations using moc (meta-object compiler), it is changed to callback functions.In Qt, events are objects, derived from the abstract QEvent class, that represent things that have happened either within an application or as a result of outside activity that the application needs to know about. Events can be received and handled by any instance of a QObject subclass, but they are especially relevant to widgets. This document describes how events are delivered and handled in a typical application.So events and signal/slots are two parallel mechanisms accomplishing the same things, in general an event will be generated by an outside entity (e.g. Keyboard, Mouswheel) and will be delivered through the event loop in QApplication. In general unless you set up the code you will not be generating events. You might filter them through QObject::installEventFilter() or handle events in subclassed object by overriding the appropriate functions.Signals and Slots are much easier to generate and receive and you can connect any two QObject subclasses. They are handled through the Metaclass (have a look at your moc_classname.cpp file for more) but most of the interclass communication that you will produce will probably use signals and slots. Signals can get delivers immediately or deferred via a queue (if you are using threads) A signal can be generated
- First of all let's define what we mean by 'Qt event' exactly: a virtual function in a Qt class, which you're expected to reimplement in a base class of yours if you want to handle the event. It's related to the Template Method pattern.Note how I used the word "handle". Indeed, here's a basic difference between the intent of signals and events:You "handle" eventsYou "get notified of" signal emissionsThe difference is that when you "handle" the eventWhen a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop., you take on the responsibility to "respond" with a behavior that is useful outside the class.
- Node.js, d-bus, other solutions
- The libevent API provides a mechanism to execute a callback function when a specific event occurs on a file descriptor or after a timeout has been reached. Furthermore, libevent also support callbacks due to signals or regular timeouts. libevent is meant to replace the event loop found in event driven network servers. An application just needs to call event_dispatch() and then add or remove events dynamically without having to change the event loop. Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX select(2), Windows select(), poll(2), and epoll(4). The internal event mechanism is completely independent of the exposed event API, and a simple update of libevent can provide new functionality without having to redesign the applications. As a result, Libevent allows for portable application development and provides the most scalable event notification mechanism available on an operating system. Libevent can also be used for multi-threaded applications, either by isolating each event_base so that only a single thread accesses it, or by locked access to a single shared event_base. Libevent should compile on Linux, *BSD, Mac OS X, Solaris, Windows, and more.
- 4:30 – wrap up our world tour of other implementations and how they do things and think about what this means for implementing and dealing with even programming in PHP
- 4:40 – Start into Best PracticesThese are, of course, my opinions on the subjectBut most people in programming have opinions for how and why to do things
- Request response is a poor eventer
- Event driven programming is a paradigm useful for abstracting events and allowing your game to react accordingly to them. This is different from Flow-Driven Programming, which is more linear consisting of a clear path from start to finish. Events provide a level of abstraction away from user input. This makes it easier for games to handle input from a variety of locations since your mouse and keyboard class can send a user movement event just as easily as your winsock network class. Passing data between classes becomes easier and more natural as each class is given the ability to listen for relevant events. State is sooo important
- Pub sub if the event system is decoupledEvent/handler Signal/slot for tightly coupled with objectsSince observersare statelessReactor – gets events concurrently and multiplexes them into the main loopname it for what it is! don’t be making stuff up
- we should have some of these standard interface lying about – the way things are done REALLY doesn’t changeHow would you define some “standard” interfaces for this stuff?Pull open editor and sketch some out if timebottom line – create a nice marker interface at the very least that can tell people “what this does” if you’re writing a libraryif you were to do it right, you’d kind of chain things down with objects, but their implementations would be much differentlimitation of PHP I guess
- Here’s where I lecture on no matter how good your system is – stand on the shoulders of giantsRemember how long the kernel or xlib or gtk/glib have been around. They’ve already worked out the kinks. Look at things like accumulators, etc.
- 4:45 – wrap up with a quick tour of places you’ll see events/signals/observer patterns “in the wild”
- An Event Manager is an object that aggregates listeners for one or more named events, and which triggers events. A Listener is a callback that can react to an event. An Event is an action. Typically, an event will be modeled as an object, containing metadata surrounding when and how it was triggered -- what the calling object was, what parameters are available, etc. Events are also typically named, which can allow a single listener to branch logic based on the current event (though purists would argue you should never do this).
- again, we have a message queue in sfEventDispatcherI would argue that arbitrary user data, event bubbling, and accumulators (all which exists in all these other frameworks discussed) are far more powerful and useful
- Like ZF2 this uses a central signal collection to compose and collect the signals before they are handled
- Quick list of all the resources for event driven programming information
- 4:50 – wrap up and questionsTO make PHP more event driven in general there’s still a lot that needs to be doneAlthough there’s a lot of support coming from some of the frameworks, in general there aren’t good, solid stand along eventing libraries available in PHp the way there are in other languagesAlso there aren’t a lot of blog posts and articles detailing the right way to do things and what event programming is all about (and why it’s good)And finally PHP needs some good C warriors (or just some mediocre ones with time to sit in irc and code)but userland as well – where is php’s twisted? or php’seventmachine?
- Let’s wrap it up and wake up – wrap up around 4:50 with questions (and they’ll be hungry)