stéphane ducasse wrote:
[lots of stuff snipped]
>> Trying to keep preliminaries as short as possible, we have as 
>> organizational elements (for the sake of discussion): system 
>> categories, classes, message categories and methods. The unit of 
>> source code "entity" we consider to be a unit of change belongs to one 
>> of these elements. We can add, replace, rename and delete. We have not 
>> only methods, but also DoIt's (definitions, organizational, etc) to 
>> take into account. And let's say that the browser is our tool, just to 
>> keep it simple here.
> 
> I would really like to have a distinction between Doit and definition. 
> Because this way we could build much clever tools. In VW classDef are 
> not doit and you can eliminate doits when you want to do a replay all.
> 
> Do I understand correctly by saying that this would be a component that 
> could be put between the sources/changes and MC for example.

I would like to make a point that Doits should not be
a separate concept:
I am aware that it is common practice to have Doit
methods in workspaces, for example.
For a long time now, I and my colleages have stored all
the Doits as methods in a Script class made for this purpose.

The rationale is that Doits are part of the code,
and should be treated the same by the CM system (Envy in our case).

This works out very well. I especially like the fact that
refactorings reliably catch the Doits as well, since they are
normal methods.

I cannot see any disatvantages from this approach, and it keeps
things really simple, imho.

Thanks,
Wolfgang