KCP looking for external reviewers

Tim Rowledge tim at sumeru.stanford.edu
Sat Apr 5 21:14:34 UTC 2003


Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
 
> Do you want us to send emails in the mailing-list about what we will do?
In an ideal world, yes; at least at the beginning. Then we would find a
group of people interested in the project and either email with them
regularly or as you are doing use a swiki. But certainly at the
beginning of any project (I'm trying to be very general here so please
don't read any of this as direct criticism of you or anyone in
particular) it would be good to see some very public discussion of
things like
+ should it be done?
+ is anyone else already looking at it?
+ has anyone tried something similar before and got ideas or cautions?

It would probably be a good idea to do a public email again when any
really big idea comes up as well. Unfortunately everyone is busy and
misses emails and then gets confused and .... life is like that. To
quote Pink Floyd "It doesn't have to be like this. All we have to do is
keep talking"


> > 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.
I hope we've all learnt from that experience. Except for java projects,
which I hope get utterly bogged down in similar problems.


> Or propose any other means.
I hope the above explains some more of what I meant. To be honest I find
it quite miraculous that we are able to communicate so well across so
many native languages and timezones and experiences. As long as we're
able to remember that we're all trying to make things better I suspect
we can get past any problems. I mean I can remember UK being at war with
Argentina but here I am working away on a project with a bunch of
friends in .... Argentina!

Regarding you swiki page notes:-

>  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.
Excellent strategy. Oddly enough I'm just doing a little work in the
area of removing direct UI connections from Class>fileout (etc) so
perhaps my changes will interest you. I'll send them when I've finished
a couple more parts, enough to illustrate the idea. Raising an exception
with a clear defaultAction and having UI related tools handle them when
approriate is a big improvement, although we will have to do a lot of
explanation and education to get people to 'do it right'.

> 
>   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.
SystemDictionary has way too much code as you say. It gets used as a
sort of utility repository when people can't think of somewhere actually
appropriate. Then there is Utilities, where a bunch of other code got
put for similar reasons. It would be nice to clean up both.
One could make a good argument for a change to 'Smalltalk' being an
object with all the navigation/utilities and copletely renaming the root
globals dictionary. At least that way us oldtimers wouldn't have to
remember a new receiver for #browseAllSelect: etc!

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Oxymorons: Christian Scientists



More information about the Squeak-dev mailing list