Bijan,

That's trivial to do if you bind the module context to a browser. In
this case whatever you do in the browser goes into the specified module.
A module system we used in VisualWorks did exactly that and it was
incredibly useful (and did include emphasis on those classes/methods
that were actually changed in the module).

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Bijan Parsia
> Sent: Sunday, March 03, 2002 4:54 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Generalized Object Modules Design
> 
> 
> On Sat, 2 Mar 2002, Hannes Hirzel wrote:
> 
> [snip]
> > >  Methods are compiled with respect to the current working module.
> > 
> > I consider it good to have the notion of 'working module'. 
> That would be
> > the default place where the DeltaModules are created.
> [snip]
> 
> But let's make it better than the current "working changeset". I often
> wish I could delegate all the changes to one class (or category!) to a
> specific changeset, regardless of the current working
> changeset. Especially if I want to tweak a tool (or respond 
> to a mailing
> list request) in the middle of working on some other projects. It gets
> fairly annoying to have to go back and sort the changed out 
> of my current
> projects change set just because I got all hot to pound out a fix :)
> 
> Cheers,
> Bijan Parsia.
> 
> 
>