This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: [RFA] New Event Model Prototype
- To: Jim Ingham <jingham at apple dot com>
- Subject: Re: [RFA] New Event Model Prototype
- From: Keith Seitz <keiths at cygnus dot com>
- Date: Tue, 17 Apr 2001 09:09:13 -0700 (PDT)
- cc: Fernando Nasser <fnasser at redhat dot com>, Insight Maling List <insight at sources dot redhat dot com>
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