on which method/language you are using and at which level of abstraction you're working. Most people seem to have an understanding of the word "event". The trouble is that most people mean different things by the term.
To name a few:
- ShlaerMellorMethod - events are asynchronous and can carry supplementary data to a single target object.
- SyntropyMethodology (in the essential model) events happen instantaneously and are broadcast to all objects in existence.
- FusionMethodology - The "interface model" in the analysis phase describes atomic "input/output events" amongst other things.
As for the programmatic notions:
- VisualBasic - Events are synchronous and are dispatched to the container of the component that raised them.
- The various Java AWT Event classes - we see that events are objects - unlike the Shlaer-Mellor, Syntropy, and Fusion event notions.
The UML tries to please everybody. UML (see the UmlReferenceManual?
) has these definitions:
- call events (Invoking an operation - has parameters and may return a result.)
- change events (These take no parameters and indicate satisfaction of some boolean condition.)
- signal events
- time events
As far as I can get is that an event seems, typically to have two properties:
- it is a "composite". To one viewer, it seems instantaneous. To another, however, it is an entire process. Thus, an "interrupt" is an event to some programmer, but a long thing to the person writing the interrupt handler. To that person the interrupt itself is instantaneous, but not to the person designing the hardware. Etc.
- it is the synchronization point between two systems. It occurs in each. We tried to model a message arriving over a communications link, and eventually had to fabricate the imaginary concept of a milk box (where the milkman puts the milk in the house). One system puts the message into the box, the other can choose to accept or ignore it. The event is part of the sender's system and the receiver's. Timeouts happen in only one system, but time is external to all systems.
An event is a state change that matters to someone. -- MichaelFeathers
(distilling the core of the concept)
I have heard that definition, Michael, and I think I disagree with it. It begs the interesting questions: What kind of someone - the same someone that has the state change? If my program adds 1 to X, is that an event? Is there anything that is not an event? -- Alistair
Yes. I have the tendency to abstract things away almost to nothingness. I almost said "observable state change" but I just wanted to see how many words I could trim. To me, things just are
, but whenever someone or something is able to discern some change in the world or any system, that transition can be named and classified as an event. In the case of X + 1, it seems possible to me that someone could model that as an event if they were interested in it. Breakpoints in a debugger are a kind of event to me.
Reformulation: an event is a state change that is interesting enough to have a name.
Whathisname was hiking over the ice. He took a step. and nothing happened. It wasn't an event. He took another step. and nothing happened. It wasn't an event either. He took another step. And he had discovered the north pole. The event "Whatshisname discovered the north pole" wasn't an event because of his state change. It was an event because it interacted in multiple systems IMHO. Or was it? To me, most events are interesting because they occur in multiple systems.
"I paid you" means I dropped the letter in your mailbox. Did the event occur if you haven't opened your mail, yet? -- Alistair
- I am having enough trouble understanding what one event is, and then you go and introduce asynchronous events before I am ready. This is intellectual cruelty of the first order.
To me, state change is the key. State may change as a result of our control or someone else's, but we can observe it or define events in terms of it regardless. To me, "Whatshisname discovered the north pole" is an event because the world was once in the state of having him at the very top of it.. relational state among Whatshisname and the world, not just object state.
Because of that, it all seems to depend on point of view. "I paid you" is an event if you can observe both sides of the transaction. "I put it in your mailbox" is all that is verifiable when you only see one side and "I got it out of my mailbox" is the only thing verifiable on the other. The thing is, if you are in one of the latter two local contexts, you'll never know whether the event that you notice was part of the "I paid you" event.
There is a symbol/referrent ambiguity here too. Looks like we use the word event in both senses.
So, yeah. I see what you mean about multiple systems. I see it as multiple vantage points, but it seems the same.
If you knew the answer to the question WhatIsAnEvent
, what would you do differently? If nothing, then maybe we need a better question. -- rj
Some people build model airplanes. I think about this stuff. Just weird I guess. -- mf
If you are working as a team or trying to describe a system to people outside your team you'd better check you mean the same thing by event
. If you don't your description of the timing and sequencing of activities could be wildly misinterpreted. (e.g. correct interfaces, passing signals at the wrong times... I'm sure you can imagine the bugs...)
There's nothing clever about this - its just that some words are practically meaningless, because there are so many different interpretations. Every time a programmer or modeller tells me "its simple - I just send this event, then..." I have to stop them and try to get them to spell out what they mean. I regularly handle three different concepts that just get called "events" in the literature/API and I suspect that I'm not the only one afflicted with this sort of problem.
Agreed. Have you ever run into a real-time system discussion (e.g.) where one team's "event" was another's process? If not, then the recursive nature of events may not matter. However, if you have, then one or some of the definitions in the literature will get in your way. -- Alistair
Perhaps there is no stable definition of event? Looking at the word philosophically it has the same feel as "thing", except it occurs in time. So, an event is when something is observed to arrive, change, or disappear. Furthermore the observation of an event is usually considered separate to the event itself, which immediately creates a semantic gap between the physical occurrence (some event process occurred) and its meaning (Something happened over there). Finally there is the event data itself, which characterizes an event. This is the "holy ghost" of every interaction, the transferring medium. So we have action/transfer/reaction all involved at the lowest level of analysis, and try to call it an "event". I have no answer to this, I suppose we need to verify our communication carefully, ensure like minds :).
An event is a trigger which runs a process. -- PeterLynch
(trying to be more abstract than MichaelFeathers)
But an event is a process, so an event is a process which runs a process.
To perceive a happening and to call it a name is perhaps an event. -- DonaldNoyes
An event is a point on the world-line of an entity (or process) which threads its way through space-time. An event is the basic building block of the phenomenal universe. Events are the basic units of the world, viewed as just "one damned thing after another". Most events are not significant, most events are not named, most events are not even noticed. When we begin to observe events and slap names on them, and assign significances to what happens or does not happen, it is then that the "ten thousand things arise", and our minds begin to spin vast designs, and to conceive vast systems. -- JohnReynoldsTheStudent