Re: [RFA] New Event Model Prototype

[Jim Ingham <jingham at apple dot com>]

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