InputSensor, EventSensor miscategorised?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

InputSensor, EventSensor miscategorised?

Frank Shearar-3
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
Promise, etc. All these work together. They fit nicely in the
category.

And then there's InputSensor, EventSensor and EventSensorConstants. What.

Where _should_ these classes belong? Maybe we should have a
Kernel-Device or Kernel-Input category?

(I'll not mention how Kernel's InputSensor >> #keyboard uses
TextConverter that causes a dependency on Multilingual, which of
course has a dependency on Kernel... oh, wait, I did.)

frank

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Eliot Miranda-2
Hi Frank,

On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]> wrote:
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
Promise, etc. All these work together. They fit nicely in the
category.

And then there's InputSensor, EventSensor and EventSensorConstants. What.

Where _should_ these classes belong? Maybe we should have a
Kernel-Device or Kernel-Input category?

IMO they don't belong in the Kernel at all.  I would add a UserInterface package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in there.  I'd also consider Headful and Headless packages for precursors of headful and headless apps.

(I'll not mention how Kernel's InputSensor >> #keyboard uses
TextConverter that causes a dependency on Multilingual, which of
course has a dependency on Kernel... oh, wait, I did.)

frank

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

timrowledge
It’s probably time InputSensor was laid to rest, along with the ancient primitives supporting it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Wibble" said Pooh the stress beginning to show.



Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Chris Muller-3
In reply to this post by Eliot Miranda-2
+1 for Kernel-Input or Kernel-Device.  Sensors are concerned with
bringing information from the outside world into the software system;
like the eyes and ears of the computer.

User-interface is concerned with the interactions between the software
and the user.


On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda <[hidden email]> wrote:

> Hi Frank,
>
> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
>> Promise, etc. All these work together. They fit nicely in the
>> category.
>>
>> And then there's InputSensor, EventSensor and EventSensorConstants. What.
>>
>> Where _should_ these classes belong? Maybe we should have a
>> Kernel-Device or Kernel-Input category?
>
>
> IMO they don't belong in the Kernel at all.  I would add a UserInterface
> package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in
> there.  I'd also consider Headful and Headless packages for precursors of
> headful and headless apps.
>
>> (I'll not mention how Kernel's InputSensor >> #keyboard uses
>> TextConverter that causes a dependency on Multilingual, which of
>> course has a dependency on Kernel... oh, wait, I did.)
>>
>> frank
>
>
> _,,,^..^,,,_
> best, Eliot
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Frank Shearar-3
That was my thinking, Chris. But InputSensor is, as far as I can tell,
entirely ST80-specific. It's all about keyboards and pointers _for
ST80_: the equivalent of Morphic's UserInputEvent.

The only packages that reference it are ST80 and System, and System
references it only because of #initializeStartUpList &
#initializeShutDownList. (System has, as far as I can see, had this
"soft" dependency on ST80 since at least 2010.)

Given that, ST80 actually seems like the right place for these classes.

frank

On 27 January 2016 at 02:52, Chris Muller <[hidden email]> wrote:

> +1 for Kernel-Input or Kernel-Device.  Sensors are concerned with
> bringing information from the outside world into the software system;
> like the eyes and ears of the computer.
>
> User-interface is concerned with the interactions between the software
> and the user.
>
>
> On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Frank,
>>
>> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
>> wrote:
>>>
>>> Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
>>> Promise, etc. All these work together. They fit nicely in the
>>> category.
>>>
>>> And then there's InputSensor, EventSensor and EventSensorConstants. What.
>>>
>>> Where _should_ these classes belong? Maybe we should have a
>>> Kernel-Device or Kernel-Input category?
>>
>>
>> IMO they don't belong in the Kernel at all.  I would add a UserInterface
>> package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in
>> there.  I'd also consider Headful and Headless packages for precursors of
>> headful and headless apps.
>>
>>> (I'll not mention how Kernel's InputSensor >> #keyboard uses
>>> TextConverter that causes a dependency on Multilingual, which of
>>> course has a dependency on Kernel... oh, wait, I did.)
>>>
>>> frank
>>
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

David T. Lewis
On Wed, Jan 27, 2016 at 10:24:55AM +0000, Frank Shearar wrote:

> That was my thinking, Chris. But InputSensor is, as far as I can tell,
> entirely ST80-specific. It's all about keyboards and pointers _for
> ST80_: the equivalent of Morphic's UserInputEvent.
>
> The only packages that reference it are ST80 and System, and System
> references it only because of #initializeStartUpList &
> #initializeShutDownList. (System has, as far as I can see, had this
> "soft" dependency on ST80 since at least 2010.)
>
> Given that, ST80 actually seems like the right place for these classes.

That sounds reasonable, but one sanity check: ST80 is a reloadable package
(or at least it was, and it definitely /should/ be). I think that will
still be the case if we move InputSensor to ST80, but I'd want to check
and make sure we don't break the unloadable/reloadable aspect.

This is probably a non-issue, but I can't check it right now so I'm just
mentioning it as a reminder.

Dave


>
> frank
>
> On 27 January 2016 at 02:52, Chris Muller <[hidden email]> wrote:
> > +1 for Kernel-Input or Kernel-Device.  Sensors are concerned with
> > bringing information from the outside world into the software system;
> > like the eyes and ears of the computer.
> >
> > User-interface is concerned with the interactions between the software
> > and the user.
> >
> >
> > On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda <[hidden email]> wrote:
> >> Hi Frank,
> >>
> >> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
> >> wrote:
> >>>
> >>> Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
> >>> Promise, etc. All these work together. They fit nicely in the
> >>> category.
> >>>
> >>> And then there's InputSensor, EventSensor and EventSensorConstants. What.
> >>>
> >>> Where _should_ these classes belong? Maybe we should have a
> >>> Kernel-Device or Kernel-Input category?
> >>
> >>
> >> IMO they don't belong in the Kernel at all.  I would add a UserInterface
> >> package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in
> >> there.  I'd also consider Headful and Headless packages for precursors of
> >> headful and headless apps.
> >>
> >>> (I'll not mention how Kernel's InputSensor >> #keyboard uses
> >>> TextConverter that causes a dependency on Multilingual, which of
> >>> course has a dependency on Kernel... oh, wait, I did.)
> >>>
> >>> frank
> >>
> >>
> >> _,,,^..^,,,_
> >> best, Eliot
> >>
> >>
> >>
> >

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Chris Muller-3
How could we possibly unload InputSensor?  Isn't that what generates
the events necessary to interact with the system?  IOW, you wouldn't
be able to reload ST80 without InputSensor, right?

On Wed, Jan 27, 2016 at 7:16 AM, David T. Lewis <[hidden email]> wrote:

> On Wed, Jan 27, 2016 at 10:24:55AM +0000, Frank Shearar wrote:
>> That was my thinking, Chris. But InputSensor is, as far as I can tell,
>> entirely ST80-specific. It's all about keyboards and pointers _for
>> ST80_: the equivalent of Morphic's UserInputEvent.
>>
>> The only packages that reference it are ST80 and System, and System
>> references it only because of #initializeStartUpList &
>> #initializeShutDownList. (System has, as far as I can see, had this
>> "soft" dependency on ST80 since at least 2010.)
>>
>> Given that, ST80 actually seems like the right place for these classes.
>
> That sounds reasonable, but one sanity check: ST80 is a reloadable package
> (or at least it was, and it definitely /should/ be). I think that will
> still be the case if we move InputSensor to ST80, but I'd want to check
> and make sure we don't break the unloadable/reloadable aspect.
>
> This is probably a non-issue, but I can't check it right now so I'm just
> mentioning it as a reminder.
>
> Dave
>
>
>>
>> frank
>>
>> On 27 January 2016 at 02:52, Chris Muller <[hidden email]> wrote:
>> > +1 for Kernel-Input or Kernel-Device.  Sensors are concerned with
>> > bringing information from the outside world into the software system;
>> > like the eyes and ears of the computer.
>> >
>> > User-interface is concerned with the interactions between the software
>> > and the user.
>> >
>> >
>> > On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda <[hidden email]> wrote:
>> >> Hi Frank,
>> >>
>> >> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
>> >>> Promise, etc. All these work together. They fit nicely in the
>> >>> category.
>> >>>
>> >>> And then there's InputSensor, EventSensor and EventSensorConstants. What.
>> >>>
>> >>> Where _should_ these classes belong? Maybe we should have a
>> >>> Kernel-Device or Kernel-Input category?
>> >>
>> >>
>> >> IMO they don't belong in the Kernel at all.  I would add a UserInterface
>> >> package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in
>> >> there.  I'd also consider Headful and Headless packages for precursors of
>> >> headful and headless apps.
>> >>
>> >>> (I'll not mention how Kernel's InputSensor >> #keyboard uses
>> >>> TextConverter that causes a dependency on Multilingual, which of
>> >>> course has a dependency on Kernel... oh, wait, I did.)
>> >>>
>> >>> frank
>> >>
>> >>
>> >> _,,,^..^,,,_
>> >> best, Eliot
>> >>
>> >>
>> >>
>> >
>

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

timrowledge

> On 29-01-2016, at 8:45 AM, Chris Muller <[hidden email]> wrote:
>
> How could we possibly unload InputSensor?  Isn't that what generates
> the events necessary to interact with the system?  IOW, you wouldn't
> be able to reload ST80 without InputSensor, right?

It’s been some time since I dug into it and I’m all wrapped up in transforms right now so I won’t be diverting back to it soon, but I’m reasonably certain that InputSensor is actually unused except as a superclass for EventSensor. I don't recall any places where an actual InputSensor ever gets to exist, let alone get used. In MVC projects the Sensor global is an EventSensor, for example. So ‘anyButtonPressed' as I recall uses something like primMouseButtons, which actually goes via the EventSensor version and fetches events to update the variable rather than the ancient primitive.

Some clean-up work could completely get rid of InputSensor


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Trojan:  Storage device for replicating codes...



Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Chris Muller-3
You can't unload a superclass without unloading its subclasses.  So,
let me rephrase the question:  How could EventSensor be unloaded and
then reloaded?

On Fri, Jan 29, 2016 at 11:35 AM, tim Rowledge <[hidden email]> wrote:

>
>> On 29-01-2016, at 8:45 AM, Chris Muller <[hidden email]> wrote:
>>
>> How could we possibly unload InputSensor?  Isn't that what generates
>> the events necessary to interact with the system?  IOW, you wouldn't
>> be able to reload ST80 without InputSensor, right?
>
> It’s been some time since I dug into it and I’m all wrapped up in transforms right now so I won’t be diverting back to it soon, but I’m reasonably certain that InputSensor is actually unused except as a superclass for EventSensor. I don't recall any places where an actual InputSensor ever gets to exist, let alone get used. In MVC projects the Sensor global is an EventSensor, for example. So ‘anyButtonPressed' as I recall uses something like primMouseButtons, which actually goes via the EventSensor version and fetches events to update the variable rather than the ancient primitive.
>
> Some clean-up work could completely get rid of InputSensor
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Trojan:  Storage device for replicating codes...
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

timrowledge

> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>
> You can't unload a superclass without unloading its subclasses.  So,
> let me rephrase the question:  How could EventSensor be unloaded and
> then reloaded?

Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DCBP: Detonate Chair on Bad Password



Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Frank Shearar-3
On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>
>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>
>> You can't unload a superclass without unloading its subclasses.  So,
>> let me rephrase the question:  How could EventSensor be unloaded and
>> then reloaded?
>
> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.

In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
Nothing points to InputSensor. Nothing points to
EventPointerConstants.

So why not in a postload of ST80, evaluate

    Environment current bind: #Sensor to: EventSensor

?

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: DCBP: Detonate Chair on Bad Password

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

timrowledge

> On 29-01-2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>
> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
> Nothing points to InputSensor. Nothing points to
> EventPointerConstants.
>
> So why not in a postload of ST80, evaluate
>
>    Environment current bind: #Sensor to: EventSensor

IIRC it’s just a global, so does even that much need doing?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Did you hear about Christopher Robin Hood? He stole from the rich to give to the Pooh



Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Eliot Miranda-2
In reply to this post by Frank Shearar-3
Hi Frank,

> On Jan 29, 2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>
>> On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>>
>>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>>
>>> You can't unload a superclass without unloading its subclasses.  So,
>>> let me rephrase the question:  How could EventSensor be unloaded and
>>> then reloaded?
>>
>> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
>
> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
> Nothing points to InputSensor. Nothing points to
> EventPointerConstants.
>
> So why not in a postload of ST80, evaluate
>
>    Environment current bind: #Sensor to: EventSensor
>
> ?

 Sounds reasonable, but why not use (or add) EventSensor class>>initialize?  The post load strikes me as too fancy.

>
> frank
>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Strange OpCodes: DCBP: Detonate Chair on Bad Password
>

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Frank Shearar-3
On 29 January 2016 at 20:41, Eliot Miranda <[hidden email]> wrote:

> Hi Frank,
>
>> On Jan 29, 2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>>
>>> On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>>>
>>>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>>>
>>>> You can't unload a superclass without unloading its subclasses.  So,
>>>> let me rephrase the question:  How could EventSensor be unloaded and
>>>> then reloaded?
>>>
>>> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
>>
>> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
>> Nothing points to InputSensor. Nothing points to
>> EventPointerConstants.
>>
>> So why not in a postload of ST80, evaluate
>>
>>    Environment current bind: #Sensor to: EventSensor
>>
>> ?
>
>  Sounds reasonable, but why not use (or add) EventSensor class>>initialize?  The post load strikes me as too fancy.

Because I'd forgotten I could do that :) There is an EventSensor
class>>install which sounds like it would do the right thing, but it
doesn't. It seems like the right thing to do then is to add an
initialize like this:

initialize
    Environment current bind: #Sensor to: EventSensor.

Sound good?

frank

>> frank
>>
>>> tim
>>> --
>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>> Strange OpCodes: DCBP: Detonate Chair on Bad Password

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Bert Freudenberg
On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> 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.

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.

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Eliot Miranda-2
In reply to this post by Frank Shearar-3


> On Jan 29, 2016, at 1:28 PM, Frank Shearar <[hidden email]> wrote:
>
>> On 29 January 2016 at 20:41, Eliot Miranda <[hidden email]> wrote:
>> Hi Frank,
>>
>>>> On Jan 29, 2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>>>>
>>>>> On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>>>>>
>>>>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>>>>
>>>>> You can't unload a superclass without unloading its subclasses.  So,
>>>>> let me rephrase the question:  How could EventSensor be unloaded and
>>>>> then reloaded?
>>>>
>>>> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
>>>
>>> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
>>> Nothing points to InputSensor. Nothing points to
>>> EventPointerConstants.
>>>
>>> So why not in a postload of ST80, evaluate
>>>
>>>   Environment current bind: #Sensor to: EventSensor
>>>
>>> ?
>>

Yes :)

>> Sounds reasonable, but why not use (or add) EventSensor class>>initialize?  The post load strikes me as too fancy.
>
> Because I'd forgotten I could do that :) There is an EventSensor
> class>>install which sounds like it would do the right thing, but it
> doesn't. It seems like the right thing to do then is to add an
> initialize like this:
>
> initialize
>    Environment current bind: #Sensor to: EventSensor.
>
> Sound good?
>
> frank
>
>>> frank
>>>
>>>> tim
>>>> --
>>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>>> Strange OpCodes: DCBP: Detonate Chair on Bad Password
>

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

David T. Lewis
In reply to this post by Bert Freudenberg
On Fri, Jan 29, 2016 at 11:08:34PM +0100, Bert Freudenberg wrote:

> On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> 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.
>
> 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.
>
> - Bert -
>

It looks to me like the proposed removal of InputSensor is a tiny project
that was started in 2000 (*) and probably should be brought to completion
one of these days. If we agree that it is a good idea, and if there is no
big time pressure to get it done right away, then I'm interested in doing
the work.

Dave

(*) The accessors for eventQueue are in InputSensor, but the actual instance
variable is already moved to subclass EventSensor. That looks like a work
in progress to me. And I'm always happy to try to polish up something that
Andreas started for us :-)


Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Frank Shearar-3
In reply to this post by Bert Freudenberg
On 29 January 2016 at 22:08, Bert Freudenberg <[hidden email]> wrote:

> On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> 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 -

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

David T. Lewis
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 <[hidden email]> wrote:
> > On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> 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 -

Reply | Threaded
Open this post in threaded view
|

Re: InputSensor, EventSensor miscategorised?

Frank Shearar-3
I will find another thread on which to pull, in the meantime :)

frank

On 30 January 2016 at 18:58, David T. Lewis <[hidden email]> 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 <[hidden email]> wrote:
>> > On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> 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 -
>

12