Kernel Cleaning Project (KCP) for Squeak 3.5
Last updated at 7:18 pm UTC on 4 December 2007
The new and official page of the Kernel Cleanup Project is Documentation
Currently we are focusing now on having the smallest core for Class, Behaviour, ClassDescription, and Metaclasses. We are also cleaning SystemDictionary. Soon we will start to clean Class and SystemOrganization, and the class API related to the compiler invocations to be a bit consistent
The idea is to move away from the kernel the dependency to UI, to move methods in the place they should be (for example, from class to method dictionary when this is behavior of method). No magic no new features just cleaning code and building layers around the core.
The first design changes introduced is the introduction of a class named SystemNavigation that should contain all the navigation code (browseAll...). Note that all the browse methods defined in the class SystemDictionary should be moved into this class too to avoid duplicated code and logic. But for now we will not touch SystemDictionary (yet) which has far too much responsibility. For the moment we focus on applying good OO practices on the core Class, ClassDescription, Behavior and Metaclass
- Major Next Tasks:
- Always build a solide test suite
- Look and clean the classBuilder
- Look and clean the systemOrganization (Currently under progress)
- Remove fileoutasHTML from Class
- Move fileout functionality out of the kernel in another layer
- Coherent and simple funnel for changes notification and access to changes
- Coherent and simple funnel for access to the compiler from the classes (fixes classParser and classScanner as role always complained about them been wrong)
- Cleaning and splitting SystemDictionary (there are too much responsibilities in SystemDictionary around 8 different. However some parts of SystemDictionary are used in the VM so it will take more time and we should be carefull about this one).
- Add automatic initialization + introduction of allocate/initialize (as lot of people will be afraid by this one we will have to prove it with numbers and tutorial as andreas suggested long long time ago).
- Some conventions we are slowly adopting: t means that the changeset is a t, rm means removal of a method, pullup a pullup,
- To try all this stuff, use an empty Squeak 3.5 image
- Then install by hand the changeset KCP-0000-KCPCoreTools-sd.cs.gz
- Then evaluate StewardsTools new updateFromKCPSwikiPage and all the changesets from this page will be installed. It's not magic, it's Smalltalk ;)
- For the reviewers, please review the changesets sequentially as there are dependencies between them.
- We do not modify changesets, we add new ones when we find a bug.
- Tool For Analysis KCP-0000-KCPCoreTools-sd.cs.gz
- copy of the tool of diego we should use it for adding tooling for the analysis of the kernel
- KCP-0001-MetaClassBuilder-ar.cs.gz (sm)
- fix of the classsbuilder posted by andreas
- Tests KCP-0002-MetaClassBuilderTest-ar.cs.gz (et)
- Tool For Analysis KCP-0003-Analyzer-ab.cs.gz Small scripts helping to detect (1) dependencies between classes and (2) list methods (belonging to a set of class) called by a particular class. Here some result (March 3rd 2003):
- The set Behavior, Class and ClassDescription contains 52 references of classes (i.e., Cursor, VersionBrowser, PopUpMenu, ...)
- In this 52 references, 63% of them are not included into a category starting with 'Kernel'
- If we regard now the set Object, Behavior, Class, ClassDescription the number of external reference go up to 104. And 69 or them are not belonging to a category begining with 'Kernel'
- Some simple tests are provided
- (er, et)
- KCP-0004-rmSubclassModule-ab.cs.gz Old references to #Module removed
- Test KCP-0005-CKTestDef-ab.cs.gz Define a test CleanKernelTest. This class represents the main test.
- Test KCP-0006-testRm-sbModule-ab.cs.gz Define some tests related to the KCP-0004
- KCP-0007-pullUpIsMeta-ab.cs.gz (sm) pullup the method isMeta on Behavior.
- Test KCP-0008-testPullUpIsMeta-ab.cs.gz (sm) test of KCP-0007
- KCP-0009-pullUpAllSub-ab.cs.gz (sm) pullup of allSubclasses
- Test KCP-0010-testPullUpAllSub-ab.cs.gz (sm) test of KCP-0009 – 13/03/03
Behavior>>confirmRemovalOf: moved from Behavior to SystemNavigation (sd)
Behavior>>classThatUnderstands: and Behavior>>whichClassIncludesSelector: were the same: these changesets remove classThatUnderstands: because it was alone while there are a collection of which... methods. (sd)
Simple Cleaning of System Dictionary starts.
Move all the browse methods from SystemDictionary to SystemNavigation plus fixes some glitches from the move from Behavior to SystemNavigation
To have the current change set always clean when running the tests (specially with tests creating new classes)
Move all the allMethod from SystemDictionary plus fixes some errors of the previous changeset. Thsi changeset is manually edited because the order of the changes are important to be able to load it (and the changesorter does not keep the order in which the changes have been done when fileouting).
Remove an obsolete method from system Dictionary
Empty changeset just for not having a hole in the numbering
Move sort classCategories to classOrganizer
Move power management methods to PowerManagement class
Fix allSelector on SystemNavigation (sm and trivial)
Fix SystemNavigation>>allClassesImplementing: (sm and trivial) – nb
Update senders of allClassesImplementing: to use SystemNavigation instead of SystemDictionary (sm) – nb
- Add the code for deprecation expression with Warning of Brent (once we will start to use it we should fix our way of testing that a test is deprecated). I modified it to force the user to explain what to do or why the method is deprecated.
- finalDeprecated.cs (was KCP-0063...) this version with the class comment (sd) [sm]
Below the changesets have not been approved yet
Mark as deprecated the method imagerReader, GifReader and JPEGReaderClass from SystemDictionary
Introduce a new way to test whether a method is deprecated based on the cs of Brent (0063)
Remove the beep method from systemDictionary and follow the suggestion of andreas to have beep caling the sound system when present. Pay attention to call beepPrimitive in certain location to avoid to call the sound system.
Deprecate the ImageImports related methods of SystemDictionary, introduce a class called Imports, and clean one Dictionary method and improve the instance creation interface of GraphicalDictionaryMenu and FormInspectView. Dictionary is then less dependent of UI. (yes again). Not tested in MVC.
Fix a reference to smalltalk instead of self systemNavigation in ChangeSorter
Fix a Smalltalk reference in Browser that is then replaced by self systemNavigation
Move the method defaultSelector from the class Behavior on the class CompiledMethod
Deprecate beep, beep:, playSoundNamed: from Object and create a Beeper class
Move SystemChanges functionality from SystemDictionary to ChangeSet class
Pay attention the two Changesets should be loaded one after the one. When loading them you will get a SystemChanges is still referenced. This is normal. We get rid of it after. So do not move it to Undeclared (I should retry because I always forget). Then you will have a deprecated method opening a debugger, proceed and the rest will work. You deserve an explanation: because this is a bit tricky. We cannot avoid that since we are modifying the system that produces the call to the deprecated method itself. During the load the method is changed to be deprecated, its callers too but the code currently executing the load is still the old one. When the changeset is loaded the old code is used. This is only at the end of the load that the new code is in place and that the next time the deprecated method won't be called again.
Some fixes for our tools
Move fullScreenOn from SystemDictionary to DisplayScreen
Deprecated one missing method related to the changeSet migration (KCP-0084 KCP-0085)
- (sm) small. Changesets should be under 10k.
- (cd) changes documented (reasoning is given that explains every different change made)
- (sl) SLint approved (you don't have to do what SLint says (sometimes it's wrong), but have a good reason why you didn't)
- (er) - externally reviewed (design + code, by someone other than the author, quite knowledgable with whatever is changed, and whatever else it might affect)
- (et) externally tested, as er above, also using cd, but generally making sure it doesn't break anything that uses it.
List of Suggestions (please sign so that we can ask you)
- First Analysis of SystemDictionary
- Squat classes This can give an idea of the core we could have and the cleaning should support.
- Move CharRecog out of SystemSupport.
- It looks to me like SystemDictionary>fileOutAndRemove: is incomplete since I can't see where it removes anything. Its brethren #fileOutAndRemove:retainingRoots: and #fileOutAndRemove:withOtherClasses:andOtherMessages: seem more complete but have no senders. Not sure if they should stay or go. Anyone got any ideas? (tim)
- Look at the builder problem: http://swiki.gsug.org:8080/sqbugs/751.html and the proposed fix http://swiki.gsug.org:8080/sqfixes/3182.html
- Would like to get rid of all the self inform: in the class classes because this relies on having PopUpMenu in Object which is not really good too if one day people decide to clean Object.
- Would like to remove inspect call from the class because in the long run we should do Inspector on: and not self inspect on Object. Inspecting result of certain messages could be moved into SystemNavigation.
- Instead of removing #inform:, #inspect as above, make them throw exceptions. These can be caught by morphic or mvc or seaside etc and treated properly - but the kernel isn't coupled to a particular UI (avi) We should look at TIm idea Kernel Cleaning Project (KCP) for Squeak 3.5 (sd: I never programmed something big with exceptions so may be we should ask for an expert)
- Behavior>>isObsolete has a strange definition (sd & ab) should check senders.
- Behavior>>typeOfClass contains a lot of magic numbers that are also used in ClassBuilder. Should be defined in one place (ClassBuilder) and not as magic number.
- The "Weakness weakness" bug relates directly to Behavior>>typeOfClass [bkv]
- It would be really helpful if ClassBuilder defined an API for discovering the relationship between these class-types (i.e., an #implies: API for class-types )
- The way the code is saved 1 or 2 to indicate source or change is a magic number that should be hidden and replace by method invocations.
- Behavior>>sourceCodeTemplate (should be moved into browser or at least in ClassDescription. Should a class has the responsibility to display its own template or should it be the browser. Note that this is not a real problem.) (ab & sd)
- Behavior methodDict iv should be renamed methodDictionary (ab & sd)
- Behavior>>withAllSubclasses (is the order mentioned garanty?. Note this can have a lot of implication while recompiling the system.) (ab & sd)
- Behavior>>changeRecordsAt: refers to VersionBrowser (ab & sd)
- functionality of Behavior>>firstCommentAt: should be moved into compiled method or method dictionary (ab & sd)
- functionality of Behavior>>formalParametersAt: should be moved into compiled method or method dictionary (ab & sd)
- Behavior>>firstPrecodeCommentFor: should be moved into CompiledMethod or MethodDictionary.
(MessageSet isPseudoSelector: selector)
ifTrue: ["Not really a selector"
What is really strange is that MessageSet isPseudoSelector just checks whether the symbol is one of the symbol used by the browser to know in which state it is #Comment, #Hierarchy,... (ab & sd)
- Behavior>>kindOfSubclass should be pushed down as behavior should not be aware of definition related information. (ab & sd)
- Behavior>>allUnsentMessages should be moved into systemNavigation (ab & sd)
- Make the way easier for using Environment (Namespace) with the kernel (ab)
- Draw clear limits to "what is kernel" (dvf): Class, ClassDescription, Metaclass, Behavior, SystemDictionary, eventually Object, a Bit of Compiler, CompiledMethod.
- Liberally use DVS convention to mark as "Class Extensions" methods that shouldn't be in the kernel. This will soon allow SpT to let us really know how much of a mess remains, and doesn't break anything (dvf)
- fix and tests provided by the list BCCMTestCase.st to look at
- run SmallLint (sd)
- check the code in VW and in GNU Smalltalk (sd)
- lot of Behavior methods are using class/classDescription (sd)
- remove fileOutAsHTML -> HtmlClassWriter (sd)
- remove reference to Transcript (sd)
- Utilities noteMethodSubmission: #Comment forClass: self theNonMetaClass (sd)
- Make sure notification of all kinds of code changes are noted, and complete information provided, to make sure computed models of code can be cached. And this doesn't belong in Utilities. (dvf) Exact we should have a simple and single funnel to arrive to changes logs.
- remove all the method ClassDescription>>ChoosePopUpMenu references (sd)
- create a class for all the navigation queries and move browse code there. (sd)
- Do we want to have all these references to FileStream (sd)
- Code formatting, return inside ifTrue... (sd)
- Check all the fixes nathanael did for the traits (sd)
- Redefine classOrganization as nathanael did for the traits (sd)
- Move functionality that are defined in the browser into the kernel classes and vice versa (PopUpMenu...)
- Recompilation of Array breaks: ArrayedCollection variableSubclass: #Array instanceVariableNames: '' classVariableNames: '' poolDictionaries: ''category: 'Collections-Arrayed'
- Kernel Cleaning Project (KCP) for Squeak 3.5
- Tim Bug and Fix for Browser allCallOn: does not find pluging references
- Tim and Andreas discussion on Pools
- Questions for the future: the class Class should not reference explicitly Changeset. The solution is to have the class has a model and that different tools register to get notified.
- PositionStream>>checkForPreamble: chunk refers to ChangeSet !!!!
Stef is now cleaning SystemDictionary
- Adapt the tool of diego to work on this page (sd)
- Check Andreas classBuilder fixes and tests
- Check what andreas did (sd)
- remove Smalltalk at: #Module (sd) (DONE)
- Behavior>>whichClassIncludesSelector: and Behavior>>classThatUnderstands: are the identical (sd)
- Behavior>>confirmRemovalOf: (sd)
- Behavior>>defaultSelectorForMethod: should be moved in the CompiledMethod class (rw & ab)