Hi diego and daniel

But what is important is to have a way to know what change. I 
understand the point of diego.
So may be for certain changes the MCP people should provide a log (for 
deprecated method this is easy I will implement what andreas suggested) 
of the things to check when loading a morphic related piece of code.

Stef


On Friday, May 9, 2003, at 04:40 PM, Daniel Vainsencher wrote:

> Diego, remember that you don't have to fix *everything* your changes
> break. In fact, it's impossible - you'll never know about all packages
> on SM...
>
> Don't let the removal process stop you or slow you down - what gets
> moved to a package will be the problem of it's maintainer (which is why
> it's important for such decisions to be widely known). You will have 
> the
> stablest process, and the most useful results, if you do your best to
> focus on the "framework".
>
> BTW, the removal of cycles also doesn't have to wait for the removal of
> packages - in fact, that's what enable their clean removal. Remember
> we're not interested in removals that leave dangling pointers in the
> framework, or that require the package to patch the framework when it 
> is
> loaded (would be nice if we could make doing that illegal, at least for
> packages that claim to applications).
>
> Daniel
>
> diegogomezdeck at consultar.com wrote:
>> Daniel,
>>
>>> [Vague limits of morphic]
>>>
>>> two answers -
>>> 1. Theoretically, and IMO, and an important part of your job is to
>>> bring us there, Morphic, as a framework, should have pretty clear
>>> limits. There should be a set of classes that are all needed for a
>>> Morphic UI, but don't depend on anything. And everything else is an
>>> extension. Obviously applications (Alice Games) are not in. Even 
>>> Menus,
>>> PLMs and friends are probably extensions, in the sense that they 
>>> don't
>>> are not intrinsically needed by morphic (just by many applications).
>>> My theory about how to trace and solve this kind of issue is that the
>>> unclear borders are marked by cycles - when the framework references
>>> applications that use it, that's pathological. So it should be useful
>>> to find the cycles and cut them. That's what SpaghettiTracer does. If
>>> you want to give it a shot, let me know and I'll explain more.
>>
>> This can be done, but we have to wait for all the removals first.
>>
>>> 2. On another level (where do your patches go, when you're not 
>>> changing
>>> big structure yourself), you should keep tabs on removals and other
>>> ongoing refactorings that have a Morphic aspect (even Celeste, to a
>>> small extent), and when you affect something that went into the 
>>> module,
>>> as people have said, send the patches to the maintainers. IOW, try to
>>> use the de facto package borders.
>>
>> I agree with you that it could be great. But, as you know, these 
>> ideas put
>> stones in our MCP road.  Each package removal make our work more 
>> hard.  Or
>> you have something in mind that can help here?
>>
>> The less-pain way should have been: First the cleaning and then the
>> removals.
>>
>>> Daniel
>>
>> Diego
>