Hi Bert,

> On Jan 31, 2016, at 5:42 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
>> On 30.01.2016, at 19:49, Frank Shearar <frank.shearar at gmail.com> wrote:
>> 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.
> 
> Isn’t the Kernel’s purpose to provide things to be used by the rest of the system?

I think of Kernel as the core language in terms of its self-representation, so we have classes, methods, contexts and processes and the related support.

In this sense an input scheme that is specific to a given implementation isn't at all kernel, just as I don't expect to see stdio support in kernel.  Would you agree?

> 
>> 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_.
> 
> I guess the distinction between “Kernel” and “System” isn’t quite clear to me.

Alas the circular nature of Collections Numbers Kernel and System make it difficult to draw clear boundaries.  These packages are rather incestuous but again for me the distinction between Kernel and System is between core language self-representation and core language semantics support and system semantics support.  In System we have the Smalltalk namespace (& if environments weren't in their own package they would belong here) plus all the change support to allow clients to observe changes of the state of the system, logging of doors etc.  some of this same support is in ClassDescription (compiling of source and writing it to the changes file) but that's just because we haven't done the work.  Ideally kernel wouldn't include notions of compilation either, just what's needed to represent Smalltalk code.


> But yes, it looks odd compared to the other classes in “Kernel-Processes”. Probably it was put there originally because it provide the interrupt watcher process.
> 
> Being I/O related it would fit better in “System-Support” with Beeper and Clipboard. (although System-Support looks like a catch-all category … glad you’re thinking about better organization)
> 
> - Bert -
> 
> 
>