Some Sensor refactorings ?

Serge Stinckwich Serge.Stinckwich at info.unicaen.fr
Mon Nov 14 09:27:35 UTC 2005


tim Rowledge a écrit :
> 
> On 13-Nov-05, at 2:30 PM, Bert Freudenberg wrote:
> 
>>
>> Am 13.11.2005 um 21:40 schrieb Serge Stinckwich:
>>
>>> Hi all,
>>> i started to look at the Sensor stuff. I have two questions :
>>> - there is two classes : EventSensor and InputSensor. The first  one 
>>> seems to be a replacement of the last one. Do we really need  two 
>>> classes or could we try to merge both ?
>>
>>
>> IMHO there's nothing wrong with having both classes. In a minimal  
>> image / VM the old polling InputSensor should actually still work.  
>> Which is good for getting new ports started. If the VM implements  the 
>> event primitives, the EventSensor will take over.
> 
> 
> Sadly this isn't how it works any longer. If you look deep into the  
> code (which of course allows the code to look deep into you) you will  
> see that the 'old' input sensor code cannot get to run. Once upon a  
> time entering an MVC project would awaken a simple InputSensor for  
> example. I did make some suggestions for a cleaner input handler a  
> while ago but no one seemed to care enough to even want to discuss  it. 
> There's a related email at http://lists.squeakfoundation.org/ 
> pipermail/squeak-dev/2004-February/073583.html
> 
> There isn't really anything simpler about the old polling prims than  
> the newer  sort-of event prims so we don't really have any good  reason 
> to keep them. I was planning on cutting them out sometime soon  along 
> with lots of other extraneous junk.

Ok, i stop looking at it at the moment if you plan to do refactorings here.


--                                                         oooo
Dr. Serge Stinckwich                                     OOOOOOOO
Université de Caen>CNRS UMR 6072>GREYC>MAD               OOESUGOO
http://purl.org/net/SergeStinckwich                       oooooo
Smalltalkers do: [:it | All with: Class, (And love: it)]   \  /
                                                             ##





More information about the Squeak-dev mailing list