[ENH] Alternative EventSensor

Raab, Andreas Andreas.Raab at disney.com
Sun Jul 30 04:35:51 UTC 2000


Tim,

> > [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.
> So call integerObjectOf: or positive32BitIntegerFor: ; for a freely
> declared hack to demonstrate that events can be done it's no 
> great crime to use a macro.

It's not a great crime but it's not a clean solution either. Calling
#positive32BitIntegerFor: or any such function can cause a GC in which case
the OOP provided may move and you have to keep in mind to remap it. As I
said this can all be debugged, but then again, why bother?! That's the first
part of why I don't want to expose the raw Smalltalk oop.

> > #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.
> ?? you've lost me. What details are being exposed that you 
> don't like to expose? What has time stamping masks got to do with it?

For one thing see above. For the time stamp - the value returned by
#millisecondClockValue is masked to fit into a positive SmallInteger value.
Which means if you forget to mask it or (because of overflow of the VM msec
representation) return a negative value, you will sometimes compute accurate
double click times and sometimes you won't. Again, it can be debugged. And
then again, why should there be any need for debugging it?!

> > [Re: Latest state]
> I almost agree but not quite. I think the proper answer lies in fixing
> the bad code as soon as possible. The problem ought not arise and we
> shouldn't spend all that much time trying to work around it. I would
> prefer that there were no need for any compatability with 
> InputSensor at all.

Yes and no. I agree that such code should be fixed but there are two uses
where I can see that the state based representations will be used for some
time. One is backward compatibility with MVC - I think there are still
enough pieces of code that will be used under both regimes so I think it's
important to keep these pieces going until we've got time to fix them. The
other possible use is for debug code - e.g., something like "Sensor
leftShiftDown ifTrue:[self halt]" is very convenient. And from my point of
view Smalltalk is all about convenience.

> PPS You gotta admit I proved that event driven need not have 
> anything to do with interrupt driven.

If I ever said anything like that I must have said it while being drunk ;-)
It was always clear to me that we will need some support for polling since
current OS' generally don't give you event notification at the interrupt
level. At least not for the common input events which are always almost
handled in the main thread by some polling mechanism itself (call it
GetMessage or XNextEvent or whatever).

  - Andreas





More information about the Squeak-dev mailing list