InputSensor, EventSensor miscategorised?
Locked
12
12
Re: InputSensor, EventSensor miscategorised?
 
|
On 30.01.2016, at 19:49, Frank Shearar <[hidden email]> 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? > 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. 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 - |
smime.p7s (5K)
Re: InputSensor, EventSensor miscategorised?
|
|
On 31 January 2016 at 13:42, Bert Freudenberg <[hidden email]> wrote:
> On 30.01.2016, at 19:49, Frank Shearar <[hidden email]> 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? Sure, but EventSensor isn't. "Kernel" means the most important/central part of something, and I'd argue that keyboards and mice aren't. I don't write interactive programs, I guess, so I don't want >> 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. I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all. > 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) Yeah, that sounds good. I had thought of "System-Sensor", as a possible alternative. And I agree re System-Support being the "misc" bucket. I wouldn't mind figuring out how to split that category into more meaningful units. frank > - Bert - |
Re: InputSensor, EventSensor miscategorised?
|
|
>> I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
> > I guess, for me, Kernel contains those things that are essential to a > running Smalltalk image. System contains stuff that's generally useful > to most things - most, but not all. I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded... |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Bert Freudenberg
Hi Bert,
> On Jan 31, 2016, at 5:42 AM, Bert Freudenberg <[hidden email]> wrote: > >> On 30.01.2016, at 19:49, Frank Shearar <[hidden email]> 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 - > > > |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Chris Muller-3
On Jan 31, 2016, at 12:49 PM, Chris Muller <[hidden email]> wrote: >>> I guess the distinction between “Kernel” and “System” isn’t quite clear to me. >> >> I guess, for me, Kernel contains those things that are essential to a >> running Smalltalk image. System contains stuff that's generally useful >> to most things - most, but not all. > > I've long thought that we'll eventually move Array, OrderedCollection, > Set and Dictionary to Kernel so that Collections could be unloaded... The inheritance relation won't let you do it. Collection would have to be in Kernel and that's completely wrong. And one can't represent Smalltalk programs without at least Kernel Numbers & Collections cuz all literals are either numbers or collections. So it is a pipe dream to be able to unload these. It might be nice to split Numbers into Numbers-Kernel and Numbers-TheRestOfTheCoreLibrary to distinguish between those numbers that can be literals and those that aren't, but then you'd have to add Numbers-Base to hold the superclasses of large and small integers and the floats up to and including Number. And of course similarly for Collections. But it's pain for little gain. There are other levels of organization (such as implement its of #isLiteral) that make the finer grain structure visible. |
Re: InputSensor, EventSensor miscategorised?
|
|
> On Jan 31, 2016, at 12:49 PM, Chris Muller <[hidden email]> wrote:
> >>>> I guess the distinction between “Kernel” and “System” isn’t quite clear to me. >>> >>> I guess, for me, Kernel contains those things that are essential to a >>> running Smalltalk image. System contains stuff that's generally useful >>> to most things - most, but not all. >> >> I've long thought that we'll eventually move Array, OrderedCollection, >> Set and Dictionary to Kernel so that Collections could be unloaded... > > The inheritance relation won't let you do it. Collection would have to be in Kernel and that's completely wrong. Eliot, I just mentioned the concrete classes -- that all of their dependencies (up the inheritance chain) would have to go too, was implied. I see nothing wrong with Collection being defined in Kernel. > And one can't represent Smalltalk programs without at least Kernel Numbers & Collections cuz all literals are either numbers or collections. So it is a pipe dream to be able to unload these. > > It might be nice to split Numbers into Numbers-Kernel and Numbers-TheRestOfTheCoreLibrary to distinguish between those numbers that can be literals and those that aren't, Right! I meant the same with Collections, of course. > but then you'd have to add Numbers-Base to hold the superclasses of large and small integers and the floats up to and including Number. No, just leave them in Numbers-Kernel. What need is there to distinguish between "Kernel" and "Base"? I don't see any.. > And of course similarly for Collections. But it's pain for little gain. There are other levels of organization (such as implement its of #isLiteral) that make the finer grain structure visible. I thought we were talking about identifying a minimal, "Kernel" Smalltalk system. My only comment was that Array, OC, Set and Dict, and all of the dependencies (superclasses, etc.) would need to be part of that. |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Chris Muller-3
On Sun, 31 Jan 2016, Chris Muller wrote:
>>> I guess the distinction between “Kernel” and “System” isn’t quite clear to me. >> >> I guess, for me, Kernel contains those things that are essential to a >> running Smalltalk image. System contains stuff that's generally useful >> to most things - most, but not all. > > I've long thought that we'll eventually move Array, OrderedCollection, > Set and Dictionary to Kernel so that Collections could be unloaded... > > really work. There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages. Levente |
Re: InputSensor, EventSensor miscategorised?
|
|
>>>> I guess the distinction between “Kernel” and “System” isn’t quite clear
>>>> to me. >>> >>> >>> I guess, for me, Kernel contains those things that are essential to a >>> running Smalltalk image. System contains stuff that's generally useful >>> to most things - most, but not all. >> >> I've long thought that we'll eventually move Array, OrderedCollection, >> Set and Dictionary to Kernel so that Collections could be unloaded... >> > > You'd also have to move their superclass hierarchy, Of course. That was implied. > so that wouldn't really > work. Why not? > There's no need to have a single "kernel" package containing all essential > classes, so IMHO it's better to have many kernel packages. "Many kernel packages" is what we have now. So what are we talking about then? Just moving things around to different packages based on some "improved" notion of subjective semantic classification, with no regard for the physical system dependencies? Why would that be beneficial? Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is it to have it in Collections? Is LRUCache part of any Smalltalk's Kernel? No, but if its in Collections along with Symbol, then I'm forced to remove it manually after loading "many kernel packages" if I just want a Kernel system... |
Re: InputSensor, EventSensor miscategorised?
|
|
Hi Chris,
On Mon, Feb 1, 2016 at 7:55 AM, Chris Muller <[hidden email]> wrote: >>>> I guess the distinction between “Kernel” and “System” isn’t quite clear So let's imagine we're wise and we look forward and we structure the classes in Collections to play well with the category names in Collections, so that all the superclasses of classes in Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support that are themselves Collections classes are in just those categories. Now I can unload all Collections-blah categories except Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support. Because when I look at Collections I see that those six categories are those that provide the minimal subset of Collections that supports the core language's set of literal collections. It provides more, but it is the minimum to provide Array, ByteArray, ByteString, WideString, Symbol, ByteSymbol and WideSymbol. Now, if that analysis is correct would it be better to change the package structure to have Collections-Kernel and Collections-PotPourri, with categories like Collections-Kernel-Abstract, Collections-Kernel-Arrayed and so on, or have some other convention such as a class-side method on Collection that defines the kernel categories? I don't know. I do know that there's real pedagogical value in having the six (and other) categories above, and I don't think we should reduce the navigability and comprehensibility of the system to make package structure serve the needs of decomposition rather than the needs of the newbie. The bug is that packages use categories. It's a functional compromise, but it's a little uncomfortable. But the key point is that your point above about LRUCache is a bit of a straw man. If we manage the categories in Collections wisely we can do what you want without too much difficulty. _,,,^..^,,,_ best, Eliot |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Chris Muller-4
On Mon, 1 Feb 2016, Chris Muller wrote:
>>>>> I guess the distinction between “Kernel” and “System” isn’t quite clear >>>>> to me. >>>> >>>> >>>> I guess, for me, Kernel contains those things that are essential to a >>>> running Smalltalk image. System contains stuff that's generally useful >>>> to most things - most, but not all. >>> >>> I've long thought that we'll eventually move Array, OrderedCollection, >>> Set and Dictionary to Kernel so that Collections could be unloaded... >>> >> >> You'd also have to move their superclass hierarchy, > > Of course. That was implied. > >> so that wouldn't really >> work. > > Why not? Collections package. > >> There's no need to have a single "kernel" package containing all essential >> classes, so IMHO it's better to have many kernel packages. > > "Many kernel packages" is what we have now. So what are we talking No, we don't. We have some packages with mixed roles. Instead of moving the kernel-related collection classes from Colletions to Kernel, you could just create a new package, e.g. Kernel-Collections, which would contain these. Such smaller packages can greatly simplify the dependencies between packages. Levente > about then? Just moving things around to different packages based on > some "improved" notion of subjective semantic classification, with no > regard for the physical system dependencies? Why would that be > beneficial? > > Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is > it to have it in Collections? > > Is LRUCache part of any Smalltalk's Kernel? No, but if its in > Collections along with Symbol, then I'm forced to remove it manually > after loading "many kernel packages" if I just want a Kernel system... > |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Eliot Miranda-2
Surely class categories are, like method protocols, simply convenience artefacts to aid reader comprehension and finding classes relevant to one’s work?
Using them as a semantic organisation for packages was a simplifying short-cut for Monticello but not a particularly good idea for ‘serious’ package specification. It wouldn’t (he said, waving appendages wildly) be very hard to revise MC to use a quite separate idea of category names from the browser. We’d need separated browsers for package-viewing and category viewing I guess. Is there anything terribly wrong about having a kernel-collections package that included a class or two from category Collections-Unordered, a few Collections-Processes, something from Compiler-Caches etc? And would that really require that every one of those have all the methods installed? Not to mention that an actual kernel system would require quite a few classes anyway tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Mommy! The cursor's winking at me! |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Eliot Miranda-2
>> > You'd also have to move their superclass hierarchy,
>> >> Of course. That was implied. >> >> > so that wouldn't really >> > work. >> >> Why not? >> >> > There's no need to have a single "kernel" package containing all >> > essential >> > classes, so IMHO it's better to have many kernel packages. >> >> "Many kernel packages" is what we have now. So what are we talking >> about then? Just moving things around to different packages based on >> some "improved" notion of subjective semantic classification, with no >> regard for the physical system dependencies? Why would that be >> beneficial? >> >> Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is >> it to have it in Collections? >> >> Is LRUCache part of any Smalltalk's Kernel? No, but if its in >> Collections along with Symbol, then I'm forced to remove it manually >> after loading "many kernel packages" if I just want a Kernel system... > > > So let's imagine we're wise and we look forward and we structure the classes > in Collections to play well with the category names in Collections, so that > all the superclasses of classes in Collections-Abstract, > Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, > Collections-Strings and Collections-Support that are themselves Collections > classes are in just those categories. Now I can unload all Collections-blah > categories except Collections-Abstract, Collections-Arrayed, > Collections-Exceptions, Collections-Sequenceable, Collections-Strings and > Collections-Support. Because when I look at Collections I see that those > six categories are those that provide the minimal subset of Collections that > supports the core language's set of literal collections. *You* can see that, a newbie couldn't. A newbie would have no way to know what all packages would be needed to simply have a "kernel" system. They would wonder why they couldn't just load "Kernel", huh? If the hierarchy for those would be reversed, as in, Kernel-Collections-Abstract, Kernel-Collections-Arrayed, Kernel-Collections-Exceptions, Kernel-Collections-Sequenceable, Kernel-Collections-Strings and Kernel-Collections-Support, THEN we've actually got a match between the newbie's semantic notion of a "Kernel" with the actual physical reality of what the system needs. The top-level(s) of the category defines the Package. I don't believe this needs to be a compromise. Let the top-level(s) determine the package, based on *physical* dependency within the system, while the 2nd thru lower levels define the semantic (sub)categorical organization within the system. > It provides more, > but it is the minimum to provide Array, ByteArray, ByteString, WideString, > Symbol, ByteSymbol and WideSymbol. > > Now, if that analysis is correct would it be better to change the package > structure to have Collections-Kernel and Collections-PotPourri, with > categories like Collections-Kernel-Abstract, Collections-Kernel-Arrayed and > so on, or have some other convention such as a class-side method on > Collection that defines the kernel categories? I don't know. I do know > that there's real pedagogical value in having the six (and other) categories > above, and I don't think we should reduce the navigability and > comprehensibility of the system to make package structure serve the needs of > decomposition rather than the needs of the newbie. The bug is that packages > use categories. It's a functional compromise, but it's a little > uncomfortable. But the key point is that your point above about LRUCache is > a bit of a straw man. If we manage the categories in Collections wisely we > can do what you want without too much difficulty. |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by Levente Uzonyi
On Mon, Feb 1, 2016 at 12:58 PM, Levente Uzonyi <[hidden email]> wrote:
> On Mon, 1 Feb 2016, Chris Muller wrote: > >>>>>> I guess the distinction between “Kernel” and “System” isn’t quite >>>>>> clear >>>>>> to me. >>>>> >>>>> >>>>> >>>>> I guess, for me, Kernel contains those things that are essential to a >>>>> running Smalltalk image. System contains stuff that's generally useful >>>>> to most things - most, but not all. >>>> >>>> >>>> I've long thought that we'll eventually move Array, OrderedCollection, >>>> Set and Dictionary to Kernel so that Collections could be unloaded... >>>> >>> >>> You'd also have to move their superclass hierarchy, >> >> >> Of course. That was implied. >> >>> so that wouldn't really >>> work. >> >> >> Why not? > > Because that would mean moving at least 20% of the classes of the > Collections package. > >>> There's no need to have a single "kernel" package containing all >>> essential >>> classes, so IMHO it's better to have many kernel packages. >> >> >> "Many kernel packages" is what we have now. So what are we talking > > > No, we don't. We have some packages with mixed roles. Instead of moving the > kernel-related collection classes from Colletions to Kernel, you could just > create a new package, e.g. Kernel-Collections, which would contain these. > Such smaller packages can greatly simplify the dependencies between > packages. In my mind, the overarching goal at the end of the day is to have a system that is both navigable and comprehensible (as Eliot said), while at the same time being easy to configure and use. By making a bunch of new tiny packages for every node in the category-hierarchy (i.e., Collections-Abc, Collections-Xyz, Colections-Qrs, etc.), Pharo accomplished the former, while sacrificing the latter. The burden was simply offloaded to configuration. Fine-grained packages represents the worst of both worlds -- they don't necessarily solve circular-dependency issues, and yet, they greatly increase configuration burden onto users. (.. And still can't configure a truly minimal system, because even those tiny packages still contain more than is needed (albeit, not AS much more). /True/ minimalism can only be achieved by unloading behaviors (classes and methods), not packages.) |
Re: InputSensor, EventSensor miscategorised?
|
|
In reply to this post by timrowledge
Hi Tim,
On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge <[hidden email]> wrote: Surely class categories are, like method protocols, simply convenience artefacts to aid reader comprehension and finding classes relevant to one’s work? This was a /huge/ bone of contention in the VisualWorks team when we went to 5i to provide Store, given parcels in 3.0. My position was that package structure was another orthogonal property and structure than class categories. Alan Knight's position was that this was unnecessarily complex and confusing and we should use class categories as packages, as does Monticello. While I think I was right, I want to be happy. I've used Monticello for 8 years and I love it. I do love the simplicity of categories being packages. Occasionally I chafe at the difficulty that categories make in slicing off a subcomponent (one often has to introduce a name like FuBar to carve off Fu-Bar from Fu and its underlings). So while you're right that packages could be separate, and the architecture of Monticello makes that quite straight-forward, it does mean introducing a whole new level of tooling to deal with the new packaging namespace, and a lot of work to reorganize a system that is pretty-well organized right now. So I think it's best to let sleeping dogs lie and live with the situation for now. When someone embarks on a really interesting bootstrap project that constructs minimal images and provides new insights into how the system should be packaged it could be worth revisiting, but I think we have fatter fish to fry right now. tim _,,,^..^,,,_ best, Eliot |
Re: InputSensor, EventSensor miscategorised?
|
|
2016-02-01 20:43 GMT+01:00 Eliot Miranda <[hidden email]>:
And now, the categories are kind of deprecated in VW... Absolutely not visible from any Browser. The browsers with double classification were somehow troubling. Maybe the two classifications were too close (more parallel than orthogonal), or said differently, not enough efforts had been put to distinguish the two (i.e. using different vocabulary) - too many efforts for undetermined value? I too like very much the simplicity of Montiello. In regard, the efforts of Pharo for decoupling classification and package management only lead to trouble so far (compatibility oblige they didn't yet abandon classification oriented packaging if I understand it, but then they would face same problem as VW IMO). Nicolas
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |