[ENH] Alternative EventSensor

Raab, Andreas Andreas.Raab at disney.com
Sun Jul 30 01:22:25 UTC 2000


Tim,

> I don't care much how the details are done so long as they work

Well, I do if it's such a critical piece of the system :-) That's basically
why I put this out for discussion first.

[Re: ST oops]
> Huh? It makes SmallIntegers (or potentially LPIs I guess). What's
> the problem with that?

Two problems basically. #1 I simply don't like hacks like "#define
INT_OBJ(val) (((val) <<1) | 1)" if there might be a cleaner solution. #2 is
that for time stamping an accurate mask is required and forgetting it may
cause trouble. Yes, all of this can be debugged but why even bother?! There
is only one situation where one might argue that exposing the internals is
actually a good idea - which is when you want to return something different
than an Integer (such as a string). But as I understand it, for the time
being we won't have a use for anything but a number of integers so I'd
rather not expose the details too much.

[Re: Latest state]
> One possible problem with your 'latest state' details - I can't
> prove it, but I have a feeling from my ponderings that it is 
> quite important to flush the event queue down to the event 
> responsible for the state you are returning. Something about 
> getting an event later that has in some sense already been 
> handled worries me.

I had originally thought about removing the events from the queue before
returning state information but the thing that bothered me about it was that
a quick (even accidental) state check removes valuable information from the
queue which is lost for those clients who actually rely on it. E.g., if you
write a drawing program and really want to use all the mouse events coming
in, some completely unrelated sender of "Sensor mousePoint" could remove all
sorts of valuable information. Even worse, it could remove critical
information such as a mouse up event. Therefore, a tiny little piece of bad
code could affect all the good code you have. In the end, this lead me to
returning some current state and obviously (e.g., if you use "[Sensor
leftShiftDown] whileTrue") this state must be updated according to the
latest known information.

  - Andreas





More information about the Squeak-dev mailing list