[squeak-dev] InputSensor, EventSensor miscategorised?

Frank Shearar frank.shearar at gmail.com
Sat Jan 30 19:29:18 UTC 2016


I will find another thread on which to pull, in the meantime :)

frank

On 30 January 2016 at 18:58, David T. Lewis <lewis at mail.msen.com> wrote:
> Please hold off on moving anything for a few days. I'm working (in the inbox)
> on making InputSensor go away.
>
> Dave
>
>
> On Sat, Jan 30, 2016 at 06:49:17PM +0000, Frank Shearar wrote:
>> On 29 January 2016 at 22:08, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> > On 29.01.2016, at 22:28, Frank Shearar <frank.shearar at gmail.com> wrote:
>> >>
>> >> initialize
>> >>    Environment current bind: #Sensor to: EventSensor.
>> >>
>> >> Sound good?
>> >
>> > Nope.
>> >
>> > You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
>> >
>> > The easiest thing would be to simply move InputSensor into the same package as EventSensor.
>>
>> They are both in Kernel. Which is where I don't want them :)
>>
>> > Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
>> >
>> > Packaging-wise the result would be the same: no InputSensor in the St80 package.
>>
>> Let's wind back a bit. I'm not really interested in InputSensor &
>> EventSensor's relationship. I care that Kernel has these classes, when
>> nothing in Kernel even uses them. They don't belong there.
>>
>> But it turns out that while ST80 still refers to InputSensor -
>> Controller class >> #initialize calls InputSensor default -
>> InputSensor default actually returns an EventSensor.
>>
>> Thing is, Sensor is referenced by a whole ton of packages - Tools,
>> Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is
>> wrong. Therefore, I think we need to put InputSensor, EventSensor and
>> EventSensorConstants into _System_.
>>
>> And we don't need any package initialization or anything else like that.
>>
>> As an aside, this investigation has revealed that Dependency Browser
>> needs an upgrade: it's not enough to know which classes in a package
>> reference which classes in other packages. Dependency Browser also
>> needs to track dependencies induced via globals - "what globals does
>> this package reference? what are the classes of those globals? in
>> which packages are those classes defined? therefore this package
>> depends on those packages.")
>>
>> frank
>>
>> > - Bert -
>


More information about the Squeak-dev mailing list