From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Ingham To: Keith Seitz Cc: Fernando Nasser , Insight Maling List Subject: Re: [RFA] New Event Model Prototype Date: Wed, 18 Apr 2001 11:39:00 -0000 Message-id: <200104181838.LAA27326@scv3.apple.com> References: X-SW-Source: 2001-q2/msg00114.html Keith, I think that the second type is more likely to be what you want. That seems cleaner, all the dispatch cares about is that it is passing event objects to everybody who claims to listen to them. Then the listener could query the event for its data - and in this case using public variables is probably a perfectly good mechanism, as long as you let people know that they really should not alter this data... As far as I know, Itcl still doesn't allow diamond graphs. But I don't think that this would cause major problems here. It means we can't subclass the EventListener and for instance have a window would inherit from BreakpointEventListener, AND ExecutionStateChangeListener. This would be nice, since then we could have the dispatch work by getting all the objects that derive from the listener corresponding to the event's most specific class. Instead, we will have to have JUST an EventListener, and then the events will use single inheritance from the base GDBEvent class to their event type. This is not as elegant, but it will work, after all, there are not that many events in gdbtk and we are never dealing with a fast stream of events, so this doesn't have to be as efficient as, say, a window server. Jim On Tuesday, April 17, 2001, at 09:09 AM, Keith Seitz wrote: > On Mon, 16 Apr 2001, Jim Ingham wrote: > >> I have another question about this. How were you planning to pass all >> the details about the event? Will there be methods in the GDBEvent >> class to get out the event data? It almost seems like you want to >> have: >> >> GDBEvent >> | >> ------> BreakpointEvent >> | >> ------> ExecutionStateEvent >> >> and ALL you ever pass to the dispatch method is an event of the >> appropriate class. This would really simplify the code in the event >> listeners, and we wouldn't get into the situation of the current code, >> where the event handlers have to know the order of the parameters in >> the >> hook call, which is very fragile. > > I agree with you guys that we would like to NOT have to pass a huge list > of arguments to the handles, but I'm not sure that this is going to work > in Itcl anywhere as cleanly as it does in C++. > > So, the proposal is to add some Event classes (which will essentially > all > be arrays of data??). Bear with me here... read the whole thing > before responding... > > Something like: > > class GdbEvent { > > protected variable _type "unknown" > > public { > proc dispatch {} { > foreach w [itcl_info objects -isa EVENTLISTENER] { > catch {$w $_type $this} > } > } > } > } > > class FooEvent { > inherit GdbEvent > > public { > constructor {args} { > set _type foo > eval configure $args > } > > variable varA > variable varB > variable varC > variable varD > } > } > > proc gdbtk_tcl_foo_event {varA varB varC varD} { > set e [FooEvent #auto -varA $varA -varB $varB -varC $varC -varD $varD] > $e dispatch > delete object $e > } > > And this would call the "foo" method of every EVENTLISTENER object with > the object as an argument. So something listening for FooEvent would > look > like: > > class MyObject { > inherit EVENTLISTENER > > public { > method foo {event} { > puts "varA = [$event cget -varA]" > puts "varB = [$event cget -varB]" > puts "varC = [$event cget -varC]" > puts "varD = [$event cget -varD]" > } > } > } > > OR the proposal is to do something like: > > class GdbEvent { > public method type {} { return "unknown" } > } > > class FooEvent { > public method type {} { return "foo" } > } > > proc GdbEvent::dispatch {event} { > set type $event type > > foreach w [itcl_info object -isa GdbEventListener] { > catch {$w $type $event} > } > } > > class MyObject { > inherit GdbEventListener > > public method foo {fooEvent} { > puts "varA = [$fooEvent cget -varA]" > puts "varB = [$fooEvent cget -varB]" > puts "varC = [$fooEvent cget -varC]" > } > } > > Are either of these on target? > > Happily, both of these address a big concern: we are constantly asking > for the same information. Now we'll have an event object to contain it > all. > > Originally, I was going to do this all with arrays, eg. event(type) = > breakpoint, event(line) = 31, event(file) = /foo/bar/baz, etc. This > way, we > can collect the info once and everyone gets to use it. But I hadn't > planned on making such a huge change to start with. I guess this is a > request to do so. ;-) > > My itcl is really fuzzy nowadays (having been corrupted by C++), so > please excuse my C++-ish approaches... > > Keith > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb