Hi tim,

>> I was thinking that this was what the people wanted because having a
>> bigger granularity will help us to go faster but may make the 
>> harvested
>> more difficult.
>> That's why we did it like that but we can change this.
> I suspect that we could handle larger granularity if there was some
> conversation during the process of making the changes.

Do you want us to send emails in the mailing-list about what we will do?
Basically we record all our ideas that emerge while reading the code in 
the wiki
This is not that clear I know but this is really the way we do it.

> That way there
> would be some decent context for the decisions and changes made
> _already_ in the reviewer's head. You might even get some useful help
> out of it.

This is what we do here. We sit by two or three and read read the code. 
Then we decide the simplest action that we could do and do it. Then 
write tests...
so this is slooooooooooow.


> I know some people (perhaps most of us?) like to go away and hide, do
> magical things and then stagger out of their cave to present a
> miraculous artifact to us all, in the hope and expectation that we will
> all gasp in admiration.

That is not our goal. Else we would do it only for us and write smart 
academic papers
we are so found of. Here the point is really basic software 
engineering. no advanced cool feature. We learned the lessons of 3.3a.

> Sometimes that even works but to be honest when
> it is code we are all supposed to share and understand and use it's
> about as useful as a chocolate teaspoon. Conversations with as many
> people as possible with an interest in the subject usually results in
> something better in the end if only because there is a larger number
> of people cheering for the project. Isn't that one of the advantages of
> open software in the first place?

So please read the wiki even if this is not really well written and 
tell us. Read the kernel code and comments on our comments.
Switching code browsing to edit this page is a pain but we try to do it.

Stef

Or propose any other means.

Here are parts of the web page http://minnow.cc.gatech.edu/squeak/3083




Currently we are focusing now on having the smallest core for Class, 
Behaviour, ClassDescription, and Metaclasses. 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
  Remove fileoutasHTML from the kernel
  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).

  Major Next Tasks:
  Always build a solide test suite
  Look and clean the classBuilder
  Look and clean the systemOrganization
  Remove fileoutasHTML from the kernel
  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 however some parts of 
SystemDictionary are used in the VM so it will take more time).
  Add automatic initialization + introduction of allocate/initialize


List of Suggestions (please sign so that we can ask you)


  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)
  Behavior>>whichClassIncludesSelector:  and 
Behavior>>whichClassIncludesSelector: are the identical (ab & sd)
  Behavior>>defaultSelectorForMethod: should be moved in the 
CompiledMethod class (sd & ab)
  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 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) (ab & sd)
  Behavior>>confirmRemovalOf: (Should be in browser and others) (ab & sd)
  Behavior methodDict iv should be renamed methodDictionary (ab & sd)
  Behavior>>withAllSubclasses (is the order mentioned garanty?) (ab & sd)
  Behavior>>changeRecordsAt: refers to VersionBrowser (ab & sd)
  Behavior>>firstCommentAt: should be moved into compiled method or 
method dictionary (ab & sd)
  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"
                         ^ nil].
  ...
  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'



>
> tim
> -- 
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Choose variable names that will not be confused.
>
>
Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html