[xinf] Events (was: Re: info for potential new developers)

[Mark Winterhalder]

On 6/16/06, hank williams <hank777 at gmail.com> wrote:
> Yeah, messagewire only sends messages to objects that subscribe to
> that message type so no object not subscribed to a particular message
> type gets any unwanted/unexpected messages. It actually effectively
> does the hashtable thing with the message name. Thats what triggered
> my thought that what we were talking about was so similar.

Well, that's one thing -- what I meant was the central vs decentral
dispatcher thing. Imagine a large number of instances of class A, each
with a number of instances of class B associated with them. All Bs
listen for event "foo", but are only interest in those from "their" A.
That's a situation I've had before and am having right now (or, as
soon as I get to that part). Anyway, that bit doesn't really matter
because both kinds would be identical, and I'm sure messageWire could
have multiple instances, too.

> Yeah you could do it this way. I am not against that. To me its really
> 6 in one hand half a dozen in the other. I guess I do like the
> separate functions because it creates highly factored code. I like
> functions to be as small and as specific as they can get. But it would
> be trivial to allow messageWire to work both ways. Youd just need to
> pass an event type as you say below.

More consensus :)

> Yes, its very cool to be able to, in real time, filter out events to
> just look for the one that you are interested in. It is amazingly
> powerful. As an example, my events might be something like "reached
> end of song" or "increment the timer clock". The timer clock event is
> one I never want to see, but seeing that a song is ended might be
> critical.
>
> It would be nice to extend it to what happens
> > after the event inside the subscriber.
>
> Thats interesting. What kind of information were you thinking of?

Well, say I have an updateData event that triggers something on the
screen to be redrawn and maybe even some other stuff. The redraw
traces a bunch of things itself, and you end up with, say, five traces
per listener. When you have a number of listeners, you get five traces
with essentially the same information from each listener, cluttering
the debug output. Whether the first of those five lines, the trace
itself, is missing or not doesn't make a difference, you still get the
same "redrawing whatever" message over and over again. So, if each
event would have an ID and every trace would have one, too, then some
modified trace could print every eventID-traceID combination only the
first time it occurred.

> I
> guess you could use a trace function that would also hook into the
> same api so you could see messages when debugging. Of course what you
> really want to do is to hook into a real debugger and have event
> reception trigger app suspension so you can inspect variables and
> context when certain events happen.

Yes, a real debugger could be nice. That's the Flash feature I miss.
It wasn't perfect, but still really helpful.

Mark

-- 
http://snafoo.org/

key: 1BD689C0 (3801 6F51 4810 C674 1491 ADE7 D8F6 0203 1BD6 89C0)