RBSqueak - what's next

danielv at netvision.net.il danielv at netvision.net.il
Wed Sep 19 16:50:45 UTC 2001


ducasse stephane <ducasse at iam.unibe.ch> wrote:
> Daniel
> 
> I do not know if you see the talk of Roel at EUg about classifications else
> look at his web page www.iam.unibe.ch/~wuyts/
Yes I have. Classifications are sets of code-like-things, similar to RB
Environments, ChangeSets and Modules (not in intention, but in
information they include), right?

> because: integration RB with Whisker is really the way to go, then having
> classifications instead of the top left pane would produce a really amasing
> browser. I already discussed with Doug we were stopped with the
> classification framework but the idea is to let you categorize anything
> (module ;), classes,methods, message send, inspected object, categories,
> favorites seletion....) as categories....
Hmm..

One time that I feel the RefactoringBrowser isn't serving me, is when I
need to do program transformations that I know are ok, even if the RB
doesn't (maybe because it's hard to prove they don't change the program,
maybe because they do, and I happen to know that's fine). Refactoring
gets to be so easy, that actually cutting and pasting code (changing the
order of statements to prepare for ExtractMethod, removing a now-useless
statement after a refactoring) feels clumsy. And also, the RB makes me
think more about several different methods together, because it can edit
them together, which makes the straight-jacket of
one-class-one-method-half-empty-code-pane even more annoying. So -

Integrate the RB with Whisker, make the code panes show SyntaxMorphs
(only make them waste less space, and make manipulation more intuitive
(yes I know, easier said than done)), and make the SyntaxMorphs stay
synched with a parse-tree or code string. Then you can do many
refactorings AND edits, and the code stays automagically legal and
compiled. And you can see across the classes and methods that are
affected by your refactoring - flipping between buffers like in the
MultiNavigator is not the way it was meant to be...

The next step - get rid of all arbitrary "documentation-only"
classifications. Feed your classifications left-hand pane all your
modules, changesets, environments you get as results of queries (does it
really make sense that the only thing I can do with the senders of a
method is browse them in a window? I don't think so). When you want the
big picture, on any of the classifications, you can call up a couple of
preconfigured CodeCrawler views.

Instead of method categories, you put computed categories like in the
Class BluePrints - creation methods, interfaces, methods, accessors. 

Now you have your browser working for you - an exquisite personal
environment for programmers... for the age of 10^8/9 hertz CPUs.

At that point it's time to really attack collaboration, and I'm not
talking just about ENVY-style tools, but more along the lines of an
internet based Tukan for each distributed projects or for the whole
community...

So much to do, so little time.

> ething up in the next few days (the
> > holiday season is starting here).
> > 
> >> Also, I am on the fixes review group, but mostly we're currently working
> >> on streamlining the incorporation of smaller fixes and enhancements.
> >> The RB is a pretty big item, which would probably be mostly up to SqC to
> >> decide to incorporate.  (The fixes review group may eventually expand
> >> its duties to look at larger items, I don't know.  Also, the notion of
> >> the "base image" will probably change a bit once a modularity system is
> >> in place.)
> > You're the maintainers of the first module - currently a very big one.
> > 
> > I think in time, some people will be maintaining modules, and what the
> > community will need is some people maintaining a Configuration of
> > *module versions* that work together well.
> 
> ;) we need a kind of envy configuration and modules with version number and
> dependencies and the dream will become reality
> 
> > 
> > The only thing that bothers me right now about the RB not being in the
> > image is that most people won't see it by default. What's required now
> > in this department is probably some cheating... :-)
> 
> Indeed this is extremely important if we could have it the image. Once I
> sent an email stating that the Refactoring Browser is really important to
> support the improvement of Squeak
> 
> > For now I'm just trying to push upstream all the changes that I think
> > should not live in the RB module.
> > 
> >> - Doug Way
> >> dway at riskmetrics.com
> > 
> > Daniel
> > 
> >




More information about the Squeak-dev mailing list