On 11.09.2012 14:35, Stéphane Ducasse wrote:
Hi igor
I started to reread again the code of EventModel that we started and I browse
the rest of the system….
gloops…
DropEvent>>sentTo: anObject
"Dispatch the receiver into anObject"
self type == #dropEvent ifTrue:[^anObject handleDropMorph: self].
DropFilesEvent>>sentTo: anObject
"Dispatch the receiver into anObject"
self type == #dropFilesEvent ifTrue:[^anObject handleDropFiles: self].
it seems to me that sentTo: is a kind of double dispatch but not yet there.
I do not see here the added value of the check except if this is to cancel
event.
Stef
I guess it's to be consistent with other types of events, and/or make it
easy to add a type instvar in the future...
Right now all three combinations of type instvar checks (KeyboardEvent),
subclassing (DropXEvents), or a mix of the two (MouseEvents) are in use
during the double dispatching of input events.
You might think subclassing was only used if additional state was
needed, but that's only true of MouseEvents, and not DropXEvents...
(So yeah, your observation that the type check in DropEvent is
unneccesary is correct)
It might be nice with a rewrite to rely on subclassing alone, albeit
increaseing the number of event classes. (KeyUp, KeyDown, KeyPressed,
MouseOver, MouseEnter and MouseLeave for sure, potentially more
depending on what action in WindowEvent means)
A benefit is you could rewrite processEvents loop to essentially read
event := MorphicEvent forBuffer: evtBuf.
self handleEvent: event
(What is recorded in recentModifiers should be queried directly from
event during handling, not through HandMorph)
And it would also make rewriting handleEvent: to something less...
intrusive wrt Event modelling a much simpler task later on.
Cheers,
Henry
