--- Allen Wirfs-Brock
<Allen_Wirfs-Brock at Instantiations.com> wrote:
[...]
> Development tools, however, must deal with invalid
> or illegal modules or 
> configurations of modules. After all, it's probably
> impossible to create or 
> edit a module without going through some illegal
> states.  This is actually 
> one of the harder parts of implementing good tools.
-- the ModSqueak team doth hereby don robes and
sandals, grab great gobs of incense, climb to the
choir loft, and sing a fervent, drawn out "AMEN".

> My sense, is that many of the "fears" of image
> people is that the goals of 
> the module people will (perhaps inadvertently) take
> away the current 
> flexibility we have of working with code within the
> image.
-- at the moment, the "ModSqueak browsers" (for lack
of a better term) have to live with a situation where
1) they can't assume everything in the image is in a
module already, and
2) they can't (well, really really really shouldn't!)
do anything to inhibit developers' using standard
Squeak tools (SystemBrowser, debugger, etc.) to write
code.

So - iirc - they follow these rules.  If a
definition's in a module, and you edit it with a
non-module-aware tool, that tool signals an event; a
ModuleManager (? - I forget its real name) is
listening for that event, and quietly keeps things
synchronized.  If it's *not* in a module, and you edit
it, that same event is signaled but the ModuleManager
ignores it.  If you create a new definition using a
non-aware tool, then the ModuleManager chucks it into
a catch-all "Unmanaged" module.

This should be neither here nor there to a developer
who isn't interested in the module structure.  As for
the rest of us, we must choose in the one case to
create modules to hold our previously-unmodularized
work, and in the other, we must decide where to move
things to when they pop up in Unmanaged.

There are obviously a lot of different ways tools
implementors could choose to do this.  ModSqueak took
as one of its first principles, "don't get in the way
of using the other tools!"

The only real flaw we've noticed in this approach so
far is the requirement it imposes on each tool to
signal the appropriate events; in the case of the
standard Squeak release, this required minor "touches"
on about 20 methods, viz., those methods which are
invoked when code's saved.  This is relatively
painless, and in any case invisible to the intrepid
Squeaker, BUT it will give nasty surprises when
tools/browsers/etc. which have not been "touched"
enter into the system.

[I forgot that last fact once, and had a real fun time
using the RefactoringBrowser, until I noticed that my
refactorings weren't making it into module-land, and
that leads to a truly confusing situation, in which
code can get quite lost.  The one thing worse than a
tools environment that doesn't work is a tool that
*appears* to work ... by which, of course, I don't
mean to slam our beloved RB, but rather my own lack of
foresight in forgetting it wasn't modularized yet.]

Willing to be convinced there's a better approach, but
going with this one for now ...

Paul

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/