On Dimanche, nov 9, 2003, at 19:33 Europe/Zurich, Colin Putney wrote:

>
> On Nov 9, 2003, at 12:06 AM, ducasse wrote:
>
>> how you format is generated right now: for me I would love to have a 
>> visitor over classDef, instVarDef, GlobalDef....that can generate 
>> different format. I was thinking how we could introduce this kind of 
>> fileouter to replace all the mess with fileouting in the image...So 
>> I'm curious to knwo in MC because I still did not find the time to 
>> have a look.
>
> Yup, that's exactly how it works. There are several visitor classes 
> that iterate over the definitions in a package to produce various file 
> formats: .st, .mc, .mcv, .mcz.

Excellent! Now I imagine that once installed you do not have the 
definitions but the run-time entity.
(In Ginsu the browser was manipulating defs and lazily (ie when a 
runtime class or method was there) the declarations were delegating to 
it.) So now if we do not have Monticello I would like to have the same 
design to fileout code. I will give a try. I imagine that the problem 
are for all the semantic elements that are not reified in the 
nonMonticello image. The Ginsu approach would be better because we 
would not have to duplicated the work.

> There are corresponding reader classes for each format as well, which 
> consume a stream and produce definitions. We used to do this by 
> evaluating chunks in a restricted environment, but it turns out to be 
> much better to just parse each chunk ourselves.
>
> Colin
>
>